Discussion on:

Rescue CDs: Tips for fighting malware

In some instances, rescue CDs are the only way short of rebuilding to ferret out stealthy malware. That said, they are not the easiest software to use.

Find out from my mistakes so you don't make them.

After running an infected computer against ESET, Malwarebytes Anti-Malware, Spybot Search and Destroy, and AVG free natively, the spyware remained. I had heard AVG had a rescue CD and tried it. It found an additional 15 infections which resolved the issue. AVG had a fairly easy to use interface. Now that I hear Avira has a better detection signatures I'll try it next time. Thanks for the independent research.

I always appreciate input like this. I wish the other rescue CDs were as easy to setup as AVG. You may find Avira a bit less user-friendly than you would like.

Let me know what you think.

Am interested in remarks / evaluation of UBUNTU ( open source ) Rescue DVD.

Greetings from Gent - Belgium

Thank you for mentioning it.

The issues with Linux as a Rescue CD mOS are:

1) File system compatibility

Ubuntu can read and write NTFS, but as NTFS is kept undocumented and subject to "feature creep", one may want to sanity-check that with every Windows revision.

2) Tools

A mOS isn't enough; you need scanners and integration checkers, too. What antivirus scanners are available for Ubuntu?

3) Registry access

With a compatble version of Windows as the mOS, you can manually bind the registry hives from the stricken hard drive and work on them. Better is to use a redirection plugin such as RunScanner for Bart, so that other tools can "see" the hard drive's hives with the expected internal paths.

In contrast, a Linux has to roll its own code to access the hives as raw files, and that's pretty scary from a compatibility perspective.

Without registry access, you can't check most integration points, but you can harvest previous hives from System restore and swap these into place for the next boot. This may knock out the integration for next boot, but expect some collateral damage.

The very first antivirus post-DOS "live CD" I found, was a BitDefender Live that used Knoppix as the mOS. It was so unstable that it never completed a scan of all files without crashing. After that, Avast released a "live CD" based on Bart PE that was beautiful, but very expensive.

Nice to see more of such initiatives, which are long overdue in a post-DOS (NTFS, 32G limit) world.

Appreciate learning about your experiences.

Clam Antivirus works well.

I have used F-Secure with a great deal of success. My only complaint is that if the PC doesn't have an "instant on" wireless connection, it doesn't catch many threats. Once it connects and updates its database, it does an amazing job - especially with the recent job I did on Protection Center rogueware. I agree that it would be nicer to have a bootable USB device where an update could be done just before beginning a job. I have clients that access the Internet using a USB modem.

Thanks for the article. I will be checking out some of the others you listed especially those that can be USB based (even my not-so-much-liked AVG)

I have had that issue as well. They will get better. I am fairly confident that others will follow AVG's example as they have the newest version right now.

You mentioned that some issues with creating USB versions of the Live-CDs. Have you looked at: UNetbootin?

http://unetbootin.sourceforge.net/

It in the article with a link.

My apologies, some how my brain skipped that.

I do that all the time. SO much to read, so little time.

The AntiVir Rescue System implies english (rescue_system-common-en.exe), but the disk it generates is in German. Video is all goofed up, too.

The BitDefender Rescue CD worked, but couldn't load my Linksys WMP54G wireless card. So definition update was not possible.

I also tried the AVG Rescue CD. It couldn't detect my Linksys wiress card either.

I'm sure the BitDefender and AVG CD will work on some machines, but 3 strikes in a row, do not impress me.

Kevin

PS> Sorry for inserting this post where it is, I meant to post it as a separate topic.

I told you to be leery of using wireless cards to update. Try hard wired connections.

Last time I used this it came up in German; however, I noticed that there was both a German and British flag in view on the lower (seems like) left. Clicking on the British flag changed the language to English.
Video-wise I have experienced a lot of problems lately (Dell machines specifically) and thus haven't been using it much.

I recently had to use a rescue CD on a friend's laptop. I decided to use F-Protect as it was highly recommended by someone in the security field. I found that updating was not straight forward and required some experimentation.

If you are trying to use F-Protect and want to update it with the latest virus definitions, see this post http://www.digitallachance.com/blog/2010/05/virus-definition-update-on-the-f-secure-rescue-cd/

I went through that as well. They have to make it easier, otherwise no one will use it.

Thanks for the link.

It seems that everything (in general, not just rescue media) I want to make into a bootable UFD requires tortuous methods. I never pick an easy one, apparently. Even the ones made with Unetbootin required extra steps, but I guess that's just how I roll.

I'll have to try out some of the distros you mention to see if they are any easier. It is a rather good list.

I have mentioned it to most concerned parties. AVG has the right idea. Hopefully others will follow.

Let us know what you find out.

USB booting can be tricky, often requiring oddball tools if you're trying to port across from diskette or optical .ISO yourself.

It's been something of a Holy Grail in the Bart community, too. Bart is built from the XP/2003 code base, and when that OS code boots, it resets the USB partway through this process and therefore chops off its legs - BSoD time!

From what I remember - and I gave up on this long ago - the fixes were either to use the Server 2003 code base (or "lift" certain key files from there), or spawn a large RAM disk, throw the OS code into that, and then boot it from there (similar to how recent WinPE versions work).

The approach I tried, involved booting the USB flash drive into DOS and then using Grub4DOS to boot Bart from there. This too did not work, and failed in a way other than I'd have expected if it were the "USB reset" issue.

So, kudos to those av vendors who provide this conversion within thier Rescue products. The best even unpack the downloaded .exe directly to optical disk (I haven't tried the USB thing yet) when run, so you don't even have to know what an "ISO" is!

Or is it better to reformat and reinstall everything?
What is the chance that an infection is not detected?

If it's an option. I'd say that a clean reinstall or last good recovery image is the way to go. It's far faster than hunting infections in the broken system. You'll also never be sure if an infected system has been truly cleaned or not. (Once breached, never trusted)

This is compounded by AV being primarily a reactionary tool. All you have to do is write something that doesn't match currently known signatures and your invisible to the majority of scanners. Heuristics helps but still has a high false positive rate.

For me, the options would be rebuild if at all possible. If not possible, run all of these against the system to hopefully find some confidence that the breach has been resolved.

Rebuilding can be a problem though. Unless the computer is totally locked down, re-imaging will still require setup time to get it back to where the user had it.

I'm told the latest production version of MS-LDAP gets very good control over the system. If your on an AD enabled setup that may be able to provide the fine adjustments after the reinstall. Lacking that, I rely on .cmd scripts for what I'm able to manipulate that way; services, a couple of registry inserts. It's not perfect though by any means.

I am not an AD expert, just enough to be dangerous. So, I keep it as simple as possible.

It is also a hard one to answer. I look at it from what kind of a comfort level I have. If the rescue CD found something and the computer returned to normal operation, I might run MBAM and GMER to be careful.

That said, if I have any doubt, I will rebuild, hopefully off of an image.

with you Michael and always run MBAM after using other tools such as the live CDs. In the last couple of weeks I have incorporated another so-called "unlikely" candidate for cleanup, Microsoft's own Security Essentials. I've seen a system unable to update MBAM and even kept MBAM from running that allowed me to get Security Essentials installed, updated and it cleaned up what was blocking the system and internet. So good job Security Essentials!

I have many colleagues that agree Security Essentials is useful AV app.

Well, I agree a reformat and reinstall is the best (and surest) remediation, but sometimes it's just not possible!
What if the owner or end-user doesn't have the installation media?

In any case, once I've cleaned the hard drive with a Rescue CD, I:
1) verify the PC is disconnected to the Internet
2) Verify the PC boots without error (missing system files, etc)
3) Uninstall the existing antivirus/antispyware product(s)
4) Reinstall antivirus/antispyware product(s)
5) Reconnect to the Internet and update all definitions
6) Reboot in Safe Mode and scan all connected hard drives.

I make sure to do steps 3 through 5 because the existing product(s) were most likely comprised by the malware infection.

Not as comforting as a reformat and reinstall, but sometimes it's the next best thing.

My $.02.

One that I might add is to use a hub and check out the computer in question with WireShark. Just to see if it's phoning home. That is becoming one of the most telling signs of malware.

that many virus/trojans will hide in the system restore section. While some people say therefore don't let system restore run at all, that is not the best answer as it can be useful. My method of operating in this regard is to jump onto the sytem logging in using Safe Mode and disable the system restore before quickly shutting down the system. Then run the live distro CDs mentioned for great success! Other items that can stick in the system are Root Kits and that's a whole other story and hair pulling. In the case of root kits it's not usually a good use of time and energy to try to find them and that's when I do a system re installation - after backup of data of course;)

Root kits are a whole different animal and if I have a hint of one it rebuild immediately.

Actually, a Rescue CD is the best way to tackle rootkits - they are just more roadkill (inactive files) when managed "from orbit", without running the code.

You can also compare tests done from the mOS boot vs. OS boot, to spot rootkit-mediated differences. For example, if your infected OS is XP, and a rootkit is hiding itself from HiJackThis, then comparing that result against a HiJackThis log done from Bart via RunScanner registry redirection will show up the extra items visible only from Bart. Gotcha!

However, that presupposes the scanners you use can detect the (now unhidden) rootkit files, and/or that your inspection of integration points (which is more difficult without RunScanner) will recognize the bad guy. The risk of failure here is exactly the same - no worse - than any other malware, when you are operating "from orbit" (i.e. a Rescue CD boot).

However, there's a caveat to be aware of. Certain tools depend on "live" behavior, and won't work when run "from orbit" because the behavior they see is that of the Rescue CD. I find this happens with driver and service ennumeration tools, LSP checkers, and particularly rootkit detectors.

In other words; if you think you need to run rootkit detectors to detect rootkits, you won't find a Rescue CD useful - because the very thing that makes it so effective at detecting malware in files, prevents it from detecting rootkits on a runtime behavior basis. Instead, you'd expect more success from general scanners and integration checkers, as the rootkit's effects are defeated by the Rescue CD.

Here's an analogy; let's say your detection strategy for tigers is to poke suspected tigers with a stick, to see if they bite. This "works" normally, but if you adopt a safer and stronger approach by first pumping the building full of sleeping gas, it no longer works because the drugged tiger no longer bites, so you don't see the expected results.

I see your point. I have just not had much success removing what I thought was a rootkit. I am concerned that rootkit malware is more sophisticated and usually has the ability to morph. Meaning that antimalware will not have the right signatures.

If you can have faith in your scanners, then the most important thing to get the jump on malware is formality of scanning, i.e. ensuring your code gets airborne and can bomb the bad guys while they are still asleep on the runway.

In contrast, the usual approach - try scanning from within the infected system - is like coming home to find your front door broken, then shining a torch into each dark room to see if there are burglars there.

"Formality" in this sense is more than just not booting the infected OS - the surfaces of your mOS needs to be safe from exploitation, the methods you use to redirect registry access must not path in malware'd .DLLs, and IMO you should be offline so it's just you and the file set, and not the rest of the Internet.

But a bigger problem is quality of scanners; frankly, they all tend to miss stuff, even stuff that is not new (e.g. several familiar USB infectors).

There are two approaches to that; using multiple scanners, and using integration checking tools and other techniques that don't rely on mugshot recognition.

Using multiple scanners in Windows isn't easy, because most scanners want to set up as resident protection and assume they are the only software to do so. So, you're already looking for atypicaln or modified on-demand-only scanners, and a mOS can be a useful low-install-pollution fix for that.

At the other extreme is the advice to use online scanners. Now let's see; you boot an infected code base, connect it to the 'net, reach a "scanner site" via possibly malware'd DNS, drop your pants to let that site drop and run code on your box, and patiently wait online while this code looks inside all the files on your system... riiiight... is the scanner looking for "malware", or credit card numbers, login credentials, etc.? How would you know?

The problems with unremovable malware, are one of 5 possibilities: (1) You didn't detect it, {2} you detected it but didn't remove it, (3) you removed (part of) it but it came back from inside the system, (4) you removed (part of) it but it came back from outside the system, or (5) the probolems you attribute to malwatre are caused by something else.

I see (5) all the time, which is why every "huh?" PC gets the RAM testing, HD testing, file system checks, eyeball on fans and capacitors etc. before the formal malware checks start. Other examples of (5) include unexpected outgoing Internet traffic because you're running a torrent, p2p sharer, or have open WiFi that your neighbors are all over like ants in the sugar.

"Rootkit" is to modern PCs as "synthesizer" was to '70s music listening; if you couldn't figure what an instrument was, you'd guess it must be one of them new-fangled synthesizer things. After all, they can do anything!

is one that installs a kernel-mode driver so that it can filter-out all mentions of its processes and files from datastreams.

Evidently, such a rootkit was installed on my computer, and the only way that I could ever get rid of it was to nuke the HDD and re-install everything. I did not have any disk and partition "imaging" software at the time, nor an external HDD on which to store it, so the task was long and arduous. And the rootkit was continually re-installed until I had enough evidence that its origin was a website which I frequented almost daily for over ten years.

During my investigations, I tried a Bart PE CD which I had made after Windows XP SP2 was installed. However, it didn't have any anti-malware software on it. So I used a Linux Live CD but it just contained software for installing Linux on the computer. Eventually, I created and used an Ultimate Boot Disk for Windows that had some, but not enough, tools on it for finding malware.

On the face of it, the rootkit driver was not loaded and running, since the system booted from the CD. The problem then became finding and identifying which files that were stored on the HDD belonged to the rootkit. Malware scanners proved useless, apparently because they did not have a signature for any of the rootkit's files. Then again, why would they??

For Windows XP, not even Microsoft can give a definitive list of what their own installation software installs on any specific computer. Thousands of files are stored in C:\Windows, which most likely contained the rootkit's kernel mode driver and the executable which installs it, since that is the only root-level directory which is accessible during system boot.

That also assumes that the rootkit hasn't altered the bootstrap loader and/or stored files on Track 0, or in the 10 MB that all Windows OSes leave at the end of every internal HDD that they partition. The executable that installs the rootkit's kernel-mode driver could be a modified .DLL which is loaded and run by a Windows OS component during system boot (e.g., svchost.exe).

The sum of my experience was that none of the twenty-plus AV programs that I had obtained, installed and ran ever detected the rootkit. How would they?? Booting from a CD with a raft of scanners installed on it would not make any difference, unless at least one of them has some means of identifying the rootkit files that is not a signature.

None of the anti-rootkit software found anything specific, either, yet the presence of the malware was quite evident from its behavior, i.e. the activities in which it engaged while it was running. As far as I know, that rootkit's files have never been identified to this day.

Booting from CD with a raft of scanners does make a difference, in that the rootkit is not running and cannot hide itself. It is then up to the scanners to recognize it, and that may be where the failure lies.

What was the malware doing? On what basis did you suspect it was still there?

Often it is what malware does (even to defend itself) that gives it away. If it hides itself by setting Hidden and System attributes, you can spot it more easily via Dir /as /s and Dir /ah /s. If it integrates itself, you can check the integration points and spot it. If it creates a fake Recycle Bin (as many USB spreaders do) you can search the system for Desktop.ini that contains the Recycle Bin CLSID, etc.

Rootkits use deeper techniques to hide stuff, and rootkit detectors look for this behaviour by comparuing results of "low" and "high" methods of pulling the same data. If the rootkit patches one of the two methods, there will be a variance and you've confirmed the problem - but if it's user-hostile "legit" code, scanners won't detect it, and sometimes a new OS will do similar things.

Off-HD boot also potentially allows the same sort of comparison, but this time instead of comparing different methods and hoping the rootkit hasn't grabbed both, you may be able to compare the same method with and without the rootkit. You'd prolly need a deep knowledge of what you're doing, to be sure that you're looking at rootkit differences rather than differences relating to the different boot.

It isn't easy to infect pre-OS boot code, or persist such code through the OS boot process (though some ill-designed new BIOS initiatives may open new doores there). It's easy to splat standard code into the boot sectors, tho things can go wrong in various ways. If there's "rounding error" dead space at the end of partitions, you can scrub that too.

In practice, it may be other factors that facilitate prompt re-infection. Does your OS automatically do whatever a dropped AutoRun.inf says it should? If so, then storage devices and network shares may be how you're re-infected each time.

Malware can update itself via the Internet, so it's helpful to keep the PC offline for as many days as you can, before you scan it with up-to-date sigs. If it's a straight race against a baddie known to the av vendors, then this should tilt the scales in your favor. This is another advantage to preceding scanning with 24 hours RAM testing, HD surface scans etc.

An important factor I forgot to mention, is that many rootkit-like effects will persist after the malware'd killed, because they are passive; merely the result of a setting that persists in effect without the need for actice malware code to re-assert it.

The av scanner will often not clean up such things, as well as often leaving behind traces of malware that are not in themselves dangerous.

For example, if malware reasserts the duhfault "hide file name extensions" setting, a first-contact av can't know whether this is a malware effect, or the way the system was before anyway.

For another example, av will often kill a malware executable within a fake Recycle Bin, without killing the malware-dropped Desktop.ini that forces the Recycle Bin effect, or indeed the pure-malware folders that held the malware and forged settings.

The following effects are "tattoos", rather than actively-asserted rootkit effects (though active malware can defend these settings)...

1) Unsafe UI settings

Hiding file name extensions, hidden files etc. is usually not simply a matter of changing per-user settings in HKU...Explorer. Malware will usually change the HKLM...Explorer\Advanced settings that define how the UI to manage these settings will operate. Suspect this if changes don't "stick", all radio buttons are blank, and so on. methods include setting all choices to assert the same unsafe setting, or leaving the value correct but of the wrong data type (string instead of DWORD) so the UI process fails to do as you'd want.

2) Task Manager, Regedit, MSConfig, etc.

These tools are useful for detecting running processes and undoing malwatre integration, so malware will often kill them in various ways. A passive and persistent method is to apply policies that disallow the user from doing such things; sometimes you need to be "in orbit" (non-HD boot) to fix these.

3) Redirected or restrictes Internet traffic

DNS can be hijacked passively, via HOSTS, web proxy, DNS server IP addresses, IE security zone settings and so on. Check also that there aren't lowered security settings or bad guys added to the Trusted Zone.

4) Fake Recycle Bins

It's worth writing this one up specifically, because it's quite common, especially with USB infectors.

If a directory contains a Desktop.ini that defines the location as a Recycle Bin (via the appropriate CLSID), then the shell will list not the files in this location, but the collected material as seen via the Recycle Bin system. This material consists of files deleted to the bin as indexed via specific files within the bin directories themselves.

Significantly, files may reside in an "real" Recycle Bin directory, but will not be shown if they aren't in the bin's index system. So the first problem is malware living in "real" bin directories and running from there.

USB storage devices that are seen as removable (as opposed to fixed, or spoofing as optical type via U3) will have no Recycle Bin, so if you see one, it's prolly a baddie.

The other tactic is to create an arbitrary directory and drop the magic "hide me" Desktop.ini into it, then drop the malware files in there. Sometimes this will be off the root of the storage; other times there will be a RESTORE or other-named directory under there that spoofs the bin in this way. The fake bin folder may have a "normal" name, or a name that looks like the long GUID type names that you see in modern Windows when you look at the "real" Recycle Bin at a file system level.

The effects of Desktop.ini spoofing (which also include the ability to change the displayed name from what it is in the file system - used normally by the OS for "My..." and language-specific purposes) will look very rootkit-like and are very likely to be left in place after av has cleaned the malware - so this is a common problem.

5) Other

Sorry, can't think of them all! Suffice to say, if you or an "administrator" (especially a "remote administrator") can do it, then generally, so can malware.

Whenever malware-friendly problems persist after cleaning, suspect these "tattoo" effects first, before burning down the house for fear of a live rootkit.

(1) According to the Network Log of the Sunbelt Personal Firewall (SPF) something attempted to send an outbound TCP/IP packet from a closed port, so the firewall dropped it. The originating program was not identified. Since all of the other dropped packets were inbound, the arrow pointing the "wrong way" sorta stood out.

(2) While using TCP View, I could see a constant flow of connections which were "Close_Wait" and re-assigned to Process 0 (System Idle) until the OS closed them. However, none of the remote endpoints on the connections "Close_Wait" were ones to which a connection had been made by the processes which were identified in the TCP View list. Evidently, a process not shown by TCP View was making connections through or around the firewall, then dropping them.

(3) After I downloaded the McAfee Download Manager, and began running it to download their Internet Protection Suite at the time, on a 30-day trial basis, I realized that something was going on and I ran TCP View. It was scrolling dropped connections to an Akamai server reassigned to Process 0, at a rate of about 25 per second at its height (given the number of lines displayed by TCP View divided by the time that it took for a connection to scroll from the bottom to the top of the display). It was weird to see the Download Manager's connection to the same Akamai server float past, still receiving files. The scrolling continued apace until the end of the download neared. The scrolling began to decrease, then halted altogether when the Download Manager dropped its connection to the Akamai server.

Ironically, McAfee Viruscan never detected the malware. I sent many suspect files to McAfee's reception center but they never found anything.

(4) SPF also had an Application Behavior Blocking feature which, in a way, functioned as a simplified whitelist. When a program that it had never seen before ran, it would query whether to allow it to run. When a program exited, SPF "took a snapshot" of the executable. The next time that the executable loaded, SPF took another "snapshot" and compared it to the previous one. If they were not the same, then it would display a query whether to allow the program to "run modified". After the events in (1), (2), and (3) above, a gradually increasing number of executable files were reported to have been changed since their most recent execution.

Of course, some changes could be considered as likely made during software updates or upgrades. This was common for Windows XP system components for two or three days after Patch Tuesday. But some files were rarely changed by updates, and something changed them. Of course, I thoroughly investigated the possibility of hardware corruption, but found no evidence of any.

Curiously, the alterations to the executable files did not evidently affect their ability to execute, or, ordinarily, to produce valid output from valid input. Comparing files to current copies seldom revealed anything obvious, such as a change in size. Perhaps what I needed was a "file comparison" utility for binaries.

There was one notable exception, when there was some damage to a climate model that I had been running (voluntarily) for a climatology lab in the UK. Because of it, I stopped running the model, since its output would become suspect if the system was corrupted by something more malicious than the "undetectable rootkit" appeared to be.

Nonetheless, over the course of three to six months, the overall performance of the computer system would slowly degrade to the point where it was not worthwhile to continue without nuking and reformatting the HDD, then re-installing everything (from scratch, since the binaries were all suspect, and most corrupted in some way).

There was never any evident attempt to attach a malware executable to an e-mail message while "the rootkit" was installed.

The dropped TCP/IP packet sent from a closed port by an unidentified program became the hallmark signal that the rootkit had been reinstalled after I had nuked and reformatted the HDD, then re-installed everything. However, that event would usually be preceded by explorer.exe crashing, which it has rarely done for any discernible reason. The display on the monitor would simply freeze and nothing would respond to input or change until after I did a warm hardware reboot. Then Windows XP would launch with a BSOD, and reboot normally after the memory dump finished.

To make a very long story short, I eventually concluded that a certain web site which I frequented almost daily for more than ten years was probably the source of the "undetectable rootkit". It was probably installed while I used the services provided by the website, and effected by JavaScript or by an altered Java application (or both).

Since last Ash Wednesday, I have not returned to that web site. The "undetectable rootkit" has not been evident since I nuked and reformatted the HDD, then reinstalled everything, as I mentioned in the post to which you replied.

Edit 15 June 2010: Item (2) to correct term used by TCP View for status of connection assigned to Process 0, and item (3) to correct estimate of scrolling rate of dropped connections. Source: a message sent to Grisoft AVG Research on 2 April 2009.

First, in both of your posts, I am not sure what you mean by "If it integrates itself, you can check the integration points and spot it." -- "it" being the malware.

IMHO, we could agree that a rootkit which installs a kernel-mode driver to conceal its processes and files has "integrated" itself into the computer system. The concept and its implications were discussed by Mark Russonovich in his comments about Rootkit Revealer on the old Sysinternals web site, which is now Microsoft Sysinternals on their TechNet site.

Rootkit Revealer attempts to discover whether a kernel-mode rootkit driver is active by comparing a "high level" datastream to a "low level" datastream, which could reveal differences if the driver only hooks one stream (usually the high one).

Are there other "integration points" that you have in mind?

Note: the Windows Vista/7 Patchguard feature will not allow a kernel-mode driver to be installed on a 64-bit Intel system.

Second: "USB storage devices that are seen as removable (as opposed to fixed, or spoofing as optical type via U3) will have no Recycle Bin, so if you see one, it's prolly a baddie."

In my experience so far, whether a removable USB HDD has a "Recyle Bin" depends upon the Properties chosen for the user's desktop Recycle Bin. When I first attached the 320 GB USB Maxtor One Touch 4 HDD to the computer, my desktop Recycle Bin "contained" (by default) any files which I deleted from it, as well as files which I deleted from the primary internal HDD. The USB Maxtor had a RECYLER root directory, though, where the file data was actually stored.

However, I've since used the desktop Recycle Bin's Properties to specify that no files which are deleted from the USB Maxtor HDD are to be stored in its Recycle Bin. So, now the USB Maxtor HDD does not contain a RECYCLER root directory. Any file that I delete from that HDD is "gone forever" unless I use a file-recovery utility before it is overwritten by another file.

How do you search the system for a hidden Desktop? Or determine the CLSID of a "fake" Recycle Bin? And I've never found a way to "scrub" the 10 MB that Windows leaves at the end of the last partition of every HDD. Which is not to say that there are no tools for doing, any of these things (today), just that I haven't found them.

By the way, it always appeared to me that the rootkit was most likely to be "active" while there was a connection to the Internet. Dunno whether it ever actually found anything on the HDD that was worth sending to another computer.

And the fact that malware tends to leave traces which scanners do not remove is one sound reason to nuke and re-image the HDD after backing-up the current data. Even so, I would beware of the possibility of an infected "data file", since a .PDF can contain JavaScript which Adobe Reader (among others) will execute unless that feature is disabled.

Hi! The blog's comment management don't allow me to reply your your reply, in which you mentioned network behavior and ?altered executables as reasons to suspect a rootkit.

I don't know enough about networking to comment, but alerts on altered executables are definitely alarming, and suggest either a run-time patching in of code (if the detection is on in-memory runtime size) or an intrafile code infector, i.e. classic "virus".

I'd also wonder about the site you suspect infected you; whether it was itself infected or serving malvertisements, and why it was able to infect your PC through the web browser.

After the unsuccessful and then successful wipe and rebuild, were there differences in the backups you restored, apps you installed (esp. if from writable media), or network and/or storage device exposure? Those could also have been conduits for re-infection.

ocie3 said: 'I am not sure what you mean by "If it integrates itself, you can check the integration points and spot it." -- "it" being the malware.'

To be active, malware code needs to be present, and be run. Getting the code to run requires integration, and usually (these days) that is via an explicit integration point, usually in the registry.

Other methods include infecting the inside of existing code files, swapping a malware file into the same name as an existing code file, dropping an \AutoRun.inf into the root of a hard drive volume to run the code when navigating into that drive, name-spoofing existing or expected files so the user launches the code by accident, exploiting an internally-exposed code surface, integrating into an application instead of the OS (e.g. Normal.dot) etc.

But as at June 2010, malware is most likely to integrate via the registry, while some do infect existing code files.

Earlier, I said: "USB storage devices that are seen as removable (as opposed to fixed, or spoofing as optical type via U3) will have no Recycle Bin..."

ocie3 said: 'In my experience so far, whether a removable USB HDD has a "Recyle Bin" depends upon the Properties chosen for the user's desktop Recycle Bin.'

By "removable", I meant that the OS sees it as such. USB storage (other than real and fake optical drives) are usually treated either as fixed (partition table, etc.) or removable.

External hard drives are very likely to be seen as "fixed", so they will often have System Restore activity and a Recycle Bin.

This can cause problems when they wander off, as removable drives do, though at least recent Windows uses an installation-specific GUID to prevent different PCs or installatiosn from looking at the wrong SVI and Recycle Bin contents.

A USB device that is more obviously "removable", such as a flash drive or camera card, would not be expected to have a Recycle Bin on it (or SVI for that matter).

Desktop.ini files are generally hidden and system etc. at the attribute level; nonetheless, safe (non-default) UI settings will let you see these and non-default options within search should find them also.

There's a well-known CLSID for Recycle Bin behavior, which would be considered fake if it turned up in a filespec other than that valid for a "real" part of the Recycle Bin system. So in my experience, it's been fairly obvious... but as I mentioned, a "real" bin can be used in that way, too.

If you browse the namespace, as Windows Explorer does, you will see Recycle Bin contents (spanning all drives) in such locations. If you browse the file system, as something like Dir or ye olde pre-95 File Managers do, you'd see the actual files in those locations, as the Desktop.ini is ignored. But a more obvious giveway is the Recycle Bin icon you'll see for the folder.

OTOH, if you mean the GUID which forms the directory within a real (or fake) 'bin, that would be trickier. If the PC has a history of re-installs or dual installations, you would see this effect in all SVI and 'bin directories visible to those installations. It's a fairly reliable indicator of that sort of history, i.e. that Windows was "just" re-installed, or that the HD was dropped into another PC, and was seen by that PC's installation as a "fixed" drive.

As to "just wipe and rebuild, to be sure"; follow the logic. Effective malware won't give itself away by any visible activity, therefore every PC has to be considered potentially infected. If you give up on the ability to detect malware, what PCs do you then not burn down to the ground "to be sure"?

Actually, when the stakes are high enough, the above logic should be followed all the way down the rabbit-hole. Doing some crucial online transactions? Eithernet into a trusted Internet access (with no LAN-side systems) from a freshly-made, fully-patched read-only OS disk with firewall, and do your thing from there.

The firewall guarded against code injection attacks, so the rootkit was not altering an application in memory. The change in "the snapshot" on which the firewall alerted occurred between the most recent time that the program exited and the next time that the program was loaded. So the changes to the executable were almost certainly being made to its file on the HDD in the interim.

Installing software on a visiting computer by using JavaScript is probably a lab exercise in any significant course of instruction as to how to create a web site. Because I have been running Firefox NoScript since it became available, it had to be a web site that I trusted, and whose services required me to enable JavaScript for most or all of the web sites which had a presence on its pages. There wasn't any advertising from other firms, or hyperlinks to the websites of other firms (they want you to stay, not stray).

There were specific, reproducible events which could be considered as evidence, but they probably were not enough for the US A.G. to prosecute, although enough for the FBI to investigate if they chose to pursue it. I don't have the time to discuss them here today.

Just to be clear: first I ran Darik Horn's Boot & Nuke (DBAN) for several hours to "wipe out" the content of the HDD. Second, reformatting and repartitioning the HDD is effected by software which runs from the Windows XP Home Edition installation CD-ROM (which is my personal property), i.e., if the HDD is not already formatted and partitioned before the Windows XP installation begins.

Third, after Windows XP was re-installed, I would install the hardware drivers from their original CD-ROM discs. Then I would update the OS from the Service Pack 2 CD-ROM which I bought from Microsoft when SP2 was released. It includes Windows Firewall as well as IE 6, but, of course I didn't go surfing about the web at that point. Rather, I would reinstall some of the software that I use from original CD-ROMs. Then I would run IE 6 to access Microsoft's Update web site to download and install about 76 patches, updates and upgrades. This would be followed by downloading driver updates, then the rest of the software was re-installed from "fresh" downloads from the websites of the vendors or developers. The only files restored from backups contained only data.

If any of the data files were, for example, an image file compromised by malware, then at least one of the twenty-plus the AV scanners that I ran should have found it.

BTW, autorun/autoplay has always been disabled on my computer since it became possible to do that.

So, I am as certain as I could be that it wasn't a "classic virus" especially since I downloaded McAfee's SUPER.DAT and used it as the definitions file. At the time, it contained the signatures of over 50,000 viruses, worms, trojans, spyware, keystroke loggers, etc., and for some of the more recent arrivals on the scene, rootkits.

That's an impressive list of "integration points", although I would call them "integration methods". Somewhere among my papers and files I have a list of registry keys which can be used to launch a program. However, IIRC, they are launched by explorer.exe after services.exe has loaded everything that runs as a service (such as the AV and firewall), but I could be wrong about that.

HiJack This! and Sysinternals Autoruns show everything that they can find, and from several files such as autoexec.nt and config.nt (which are stored in c:\windows\system32). Of course, if the rootkit's kernel-mode driver is correctly designed and coded without errors, then it will filter its own files out of the datastreams between the kernel and those programs.

Someday I must read the documentation for rundll32.exe to see how it is launched. IMHO, it and svchost.exe are two of the biggest security risks in the Windows OS. Anti-malware developers have found malware that is launched by one and malware that is hosted by the other.

Given the observed propensity of the undetectable rootkit to alter executables, I always thought that was the most likely means that it used to have the installer launched during the system boot, and it would install the kernel-mode driver. But I never could obtain enough information to effectively investigate that possibility.

As to the external USB Maxtor HDD that I now have, Windows XP displays an icon in the System Tray when it detects that the HDD is attached. I can use the icon to "disconnect the hardware safely", but most of the time "generic volume F:\" cannot be removed until I run the unlocker.exe utility to remove the explorer.exe and other outdated executable locks on the drive per se. So Windows XP does recognize the drive as removable, but it would create a RECYCLER directory on it if I wanted to keep files that were deleted from the drive in my desktop Recycle Bin. While the drive is disconnected, the files that have been deleted from it are not displayed in that Recycle Bin, of course.

Last, but not least, according to Windows Explorer Search there are 139 desktop.ini files currently stored on the primary internal HDD, and it looks to me as though almost all of them have hidden and/or system attributes. Not that I think that the undetectable rootkit has returned, but if any malware is using a hidden desktop, how would I distinguish it from amongst the crowd??

Hi! I've moved my replies to a new thread in these comments, so they thread better.

The malware industry is large enough for specialities, and although any malware can have rootkit functionality, stand-alone rootkits are often used as part of an off-the-peg bundle to hide other stuff.

Intrafile code infection is fairly difficult to do, so there aren't that many folks doing it. The advantage is lack of external integration points, plus invisibility at the task file name level (though exposed to checksum tests). But it's hard to include much useful functionality within the infected files, or integrate other malware developer's code into these.

Traditional antivirus has been dealing with such infectors for ages, and one would expect prompt detection of these, as part of what differentiates a "real" av from the growing number of "antispyware" scanners that rely more on file names and integration checks.

So if you're up against an intrafile infector that a large number of av scanners (still?) can't identify, I'd worry about something more targeted than a drive-by infection, and rack up the game to include forensics, Microsoft technical support, possible law inforcement, etc.

Those 25+ av scanners; were they run within the infected system? If so, then compare that with the same scanners run formally, i.e. via these Rescue CDs. If the latter work, then you have a rootkit, else more likely "just" an unknown infector.

You may find integrity checkers helpful, if it's an unknown infector. For example, Kaspersky may create checksums held in an ADS added to the code file.

I'll discuss Desktop.ini and "removability" of external hard drives in separate post(s) in the new thread.

Anyone who has the knowledge and skill to write a kernel-mode driver which filters out all mentions of its files and processes from kernel datastreams, without errors, would have the skill to write an installer which is a modification of, or an outright replacement for, an executable file of their choice. A challenge, maybe, but not likely a difficult one.

What I would do is modify a Windows component that runs during system boot, such as services.exe, to load and run a .DLL which is the kernel-mode driver. Usually either winlogon.exe or services.exe (or both, eventually) would be reported by the firewall, after it was launched, as "running modified". But there are many choices.

All the installer has to do is install the kernel-mode driver, so it can run once per boot and exit. I've been told that such an installer is not all that large, and it is very small when it is written in "assembly language".

Of course, a rootkit's kernel-mode driver is not limited to filtering mentions of its own files and processes, it can filter mentions of any file and process. The installer and the kernel-mode driver are all they need to hide everything that they want to hide. That is why undetectable rootkits -- today -- are often found in the company of other malware, especially spyware, which can be installed on the computer by whatever conventional means is available.

Indeed, the kernel-mode driver itself does not have to be "hidden" in another file, but it may be given a read-only attribute or perhaps hidden and system attributes so that someone doesn't "accidentally" delete it.

However, as the list of files and processes grows, so does the amount of time (CPU cycles) that the driver spends filtering the streams. When a system is underperforming, so to speak, users complain and IT personnel start investigating the situation and attempting remedies.

By the way, on 32-bit systems, a kernel-mode driver is used by Ronen Tzur's SandboxIE, which creates "sandboxes" for running programs, such as browsers and e-mail clients. You might want to check it out.

Kaspersky's package refused to install because it claimed that "other anti-malware" was already installed on my computer. Since it never actually disclosed any useful details that I could use to locate the offender and remove it, I soon realized that its constant refusal was a broad hint to completely nuke the HDD, reinstall Windows XP from the installation CD-ROM, ..... You know the drill. Somehow, during such a re-installation, installing Kaspersky's AV software was never something that I thought of doing (until it was too late).

Forensics? Microsoft tech support? Law enforcement? Don't get me started!!

I like to preserve System Restore contents (along with Temp, TIF etc.) for forensics.

Malware will wind up in SR if it updates itself to stay ahead of av detection, and if something such as av deletes it and it reasserts itself (say, from another thread).

If you find the same file repeated throughout restore points, suspect re-assertion from another malware thread. If the files differ in content but are detected as the same malware, it's more likely one that repaints itself to avoid detection. If you find your detections end before the most recent restore point, and there are no "live" detectios, then either the av caught up with it or (more likely?) the strategy is still working effectively.

I manage System Restore by harvesting registry hives from restore points while in the mOS (Rescue CD) to preserve them. Then, after the Safe Cmd phase of cleaning out "soft" malware (so changes may be reversed from quarantine) and normal Windows boots and works OK, I set a new restore point, use Disk Cleanup to delete all but this new clean baseline, and gone will be all the malware.

So far, malware doesn't run from the SR store, and there is "no risk" as long as one does not do a System Restore. BUT if you do restore back to an infected state, you not only return the malware code, but the registry integration points as well, plus you may undo code updates of av and other edge-facing software.

So I do like to purge System Restore as part of the clean-up, while hanging on to the registy hives from this material (for forensics, and/or undoing changes that may break functionality).

Quote: "So far, malware doesn't run from the SR store, ...".

In my experience so far, Windows XP will not load and run any file from C:\System Volume Information (where the system restore point files are stored).

You have an interesting take on System Restore, though.

You're going to see a lot of "nuke and rebuild, it's the only way to be sure" responses.

Neither approach will always work, and what you do may depend on the quality of the original installation. If that was well-setup and patched, falling back to a baseline patch level with duuuhfault settings and no av etc. may be more likely to be re-infected than a well-setup, well-cleaned system is to be fully disinfected.

The collateral damage of "just" wiping and re-installing is huge, especially with the typical one-big-doomed-C: setup. Are your backups OK? Drivers for all hardware? Installation disks and product keys for all software? Know all your passwords? Does your OS install disk actually work safely on your PC? If that's XP Gold and your hard drive is over 137G, the answer is No.

If you can shrug and walk swiftly away from the above, leaving it as the user's problem to sort out, then sure; you may prefer "just" wipe and rebuild.

The problem is that a freshly-rebuilt system has to go online in an unpatched and undefended state, and is thus more likely to be re-infected than the original set up that was infected before. This is all the more true if the malware involved has an awareness of co-infected systems, and will actively re-assert the infection when these re-appear after being rebuilt.

Does that happen in real life, yet? I don't know. I haven't read about it, but it would seem an obvious thing for malware to do.

Having "just" wiped and rebuilt, you've also lost all forensics as to the original infection. You know zero about your attackers, whereas your attackers may know a great deal about the system as it was, and will be.

So, if you want to be ready for "it's infected again!", then the best may be to build a new system on alternate hard drive, patch and av-install it OFFLINE, then use that while you scan the original hard drive "from orbit" (offline, non-HD-boot).

In my case it depends on whether it's my computers or a clients. It also depends on whether the client is using a generic load and the users can not personalize their systems.

Yep, you hit the nail on the head.

In a pro-IT environment, there's a pro sysadmin to ensure that all the data that matters is on the server, and that this is backed up. The users are not supposed to "personalize" their PCs (for sound organizational reasons) and such PCs can be easily re-imaged from what has been set up to work best for the organization.

In consumerland, it is very different. Not only do you have dubious data backups, and a PC that has evolved in a unique way with no easy way to rebuild this, you may also have the entire family's IT infrastructure in that one box.

If you were to advise a business to "just" wipe not only the infected PC, but every PC and server throughout the organization (and perhaps backups as well), you'd prolly be told to take a hike, no matter how effective this may be at killing the malware.

Yet in effect, this is the usual advice dished out to consumers - partly because it is pro-IT that have the loudest and most respected voices, and partly because of an arrogant assumption that end users can't possibly posess any material that "matters".

with "that a freshly-rebuilt system has to go online in an unpatched and undefended state" because both antimalware/antivirus and patches can be applied (and often are) before going online with a fresh install. It only makes sense to upgrade a system as much as possible before going online. I install much of my protection software from a USB stick which is in my pocket everyday except Sunday, my day off.

Yes, I know what you mean - you can and should patch as far as possible, install an av and update it, and ensure the firewall is on and wireless is secured before going online for the first time.

In practice, it's easy to attain the latest baseline SP level and install an av. It's more fiddly to apply all subsequent patches offline, and update the av offline, too.

The point I was trying to make, but failed to contextualize properly, is that there's no "100% effective free lunch" here. The skills you need to rebuild an arbitrary consumer's PC back the way they'd like it without promptly having it re-infected, approach those needed to clean it.

In both cases, it helps if the original installation didn't suck. However, the usual duhfault installation will fail to separate incoming crud from user data (default web browser download target "My Documents", emaul attackments hidden in mail stores, IM attachments also arriving in "My Documents", etc.) and this can bring back the problem when the PC is blindly wiped, rebuilt, and "data" is restored from backups.

How do you maintain an up-to-date all-inclusive collection of OS patches? Do you use USB flash drives, or write-protectable SD cards?

Where USB storage is concerned, I can set a PC so it doesn't auto-infect itself from USB storage (not as simple as it should be) but I can't prevent writable USB storage from being infected by malware'd systems. I'd definitely want to do that, to protect my offline update repository!

Hello,

Here a couple more titles to add to your list:

PC Tools' AOSS:
http://www.pctools.com/aoss/details/

Panda SafeCD:
http://research.pandasecurity.com/panda-safecd-3-4-3-5-released/

I've used each software title on different malware clean-up jobs and both of them worked with very good success.

Cheers!

I like it that I am getting more choices.

These scans can take hours, so how do you draw the line on how much time you spend on the customer site? I try not to spend too much time on-site and try to get the machine back to my shop. To do the job right can take many hours of research,scanning and updates, only to have to do a data-save and reinstallation anyway.

I spend very little time on site, if the problem is not clearly defined and therefore requires a re-establishing of all "assumed OK" levels of abstraction.

So PCs that "just don't work", "won't boot", "became very slow", crash in varying ways, mysteriously can't update their antivirus or use unexpectedly high outgoing Internet bandwidth, get pulled and worked on off site.

I don't bill clock time, but productive hours. I have enough old 14" CRT monitors to run several PCs in MemTest or other low-res environments, and newer monitors to run more in hi-res environments.

So hours of unattended "click and wait" don't cost the client much, and are great CYA for me; I seldom have to apologise for losing the contents of a hard drive because it was failing and I hadn't checked that, or because I "just" re-installed Windows without discovering the RAM was bad.

The full process takes some days, sped up by separating the hard drive from the rest of the PC. In-house monitoring of RAM test results (i.e. leaving PCs to MemTest86 for as long as they aren't needed, and noting how many throw thier first error after what was previously considered "long enough" to test) suggests 24 hours is close to exclusionary (only 1 PC threw its first error after that, in the last several years). By that time, the hard drive has often completed all its tests, so no extra clock time is wasted.

Sure, it's quicker to "just" wipe and rebuild, and only go "duh, maybe the hardware's bad?" when that fails to complete, and maybe if you're working for a large box-pusher or OEM under pressure from management, that's what you have to do.

It's also cheaper for the client to lean over the fence for free neighborly advice, which may go further in quality terms.

So if you're claiming to add value, i.e. be worth paying to do this properly, you should be going that extra mile IMO.

Many of my clients have files too important to back up, just to wipe and reinstall. So spending some time trying to reduce the virus probablility is worth it, before backing up these needed files. Some of them don't even mind running with malware still active on the PC, as they have no personal information on the PC in the first place; and have no data needing to be backed up. I figure it is the clients decision as long as the personal ID risks are discussed. They figure as long as the PC runs well, they can deal with the infection later.

Many times I bother to remove the malware just so I can continue to learn this; it has improved my troubleshooting skills also. I actually like doing this - however, so I can't blame IT types for nuking the drive.

When I worked as an employee on contract, our CIO didn't want us wasting time removing malware, so we would simply start over. However, we had a server image we could work with, and sometimes the individual machine actually ran better after restoring the image. This image was fully updated of course.

This way we didn't have to reinstall all application, etc. The only thing extra to do was point the clients My Documents to the network share, where their files were actually stored - unless they had a shared printer, but that wasn't too bad.

My primary mission is to try as hard as possible to prevent infection with a deep defense. This has worked pretty well, as my clients rarely need help after I get them up to snuff with the latest in security tech.

Hiren's boot cd has several malware removal programs installed. They are updateable through a wireless connection, and has firefox installed.

I have used that Live CD before and it has an amazing number of apps. It never gets tested, though. I assume it's because the Live CD doesn't have a major AV application. But, MBAM and GMER should be just fine.

I was "rescued" recently by using the Avira AntiVir CD, to eliminate a rootkit infection on my wife's Toshiba laptop. I was not able to use a USB drive as this is not an option in the BIOS. But for the one-time use that I required, burning a CD with the current (at that time) database was sufficient, and solved the problem that no other virus scan under Windows was resolving. (The Vista laptop had current AVG 9 antivirus software, but this did not stop the infestation by Koopface, which also corrupted the AVG files "to protect itself?") Creating my own Rescue CD also saved me $150 that the GeekSquad would have charged to remove the virus/rootkit. Thanks AVIRA!

I love hearing experiences like yours. Thank you for sharing.

My experience using an Avira Rescue CD is that it can do online updates over a wired connection but not over wireless. Also, keep a Windows installation CD nearby because if any system files are infected and you choose to rename them or delete them (these are options you choose before scanning) then you may not be able to boot your computer after it's been cleaned. In this case I suppose a repair installation would be required and thats what the Windows installation CD is for.

I agree completely, very good advice.

wholeheartedly. Great practice.

The easiest way to replace the infected system files is the recovery console (in Windows XP) or the WinRE recovery disk (in Vista and 7). Both can be accessed from the Windows CD or DVD (if you are lucky enough to get one).

Recovery Console is particularly useful for fixing early-boot issues such as bad boot records and Boot.ini, but isn't an OS, in that it can't run other programs.

It also needs pre-applied settings if it is to access drives other than C:, and even then, it can't do wildcard copies, so it's not useful as a way to evacuate a system before "just" wiping and rebuilding it.

In contrast, WinPE is a bootable subset of Windows that should be able to run more programs than it does in practice. Getting WinPE was obstructed by licensing issues until Vista; since then, you can download the massive Windows AIK that includes it.

Bart PE is a free alternative to WinPE, developed by Bart. It's a small download, and has a well-developed plugin architecture to integrate other software, but it is bound to the XP code base. Unlike WinPE, it has a GUI as well as command line interface.

WinRE is an offshoot of WinPE, replacing XP's Recovery Console as it includes similar "fix it for me" tools.

If you didn't get shafted by the big-brand practice of "recovery" disks (or worse, hard drive material and no disks at all) then your Vista or Windows 7 DVD can function as a "WinPE", offering as it does the same command line OS. Long overdue!

Windows NT won't work (boot) if you copy it as loose files from one hard drive to another, even if you copy all files, assert the correct boot records and code, etc. For this reason, you should use a partitioning image tool to back up C: (and is a good reason to keep C: small).

BING (Boot It NG) can do this, as can DriveImage XML (free). BING is a bootable disk in itself; DriveImage runs from Bart. I haven't tried DriveImage from 32-bit or 64-bit WinPE and related MS bootable disks.

There's a very real risk that a formal (Rescue CD, or other methods that ensure the infected code base does not run) cleaning will knock out crucial files and prevent the system from booting thereafter.

But even when a repair install is possible (XP or older, a full installation disk is to hand, the product key is known, the disk is safe for the size of the hard drive), it has undesibale effects, such as losing patches, spawning new user accounts, resetting activation status and needing device drivers.

A cleaner approach is to ensure you log all the files that are cleaned, and re-apply these via your Rescue CD, or (at a pinch) the Recovery Console.

If the OS is XP or 2000, you can use the Nirsoft ProduKey tool from a Bart Rescue CD via the RunScanner plugin, to get the installation's product keys as required when you "just" do the repair install.

Unfortunately, what happens in a lot of shops, is not only does the tech resort to "just" re-installing Windows far too easily, but a warez XP install disk is used to avoid activation hassles. And because all warez costs the same ("zero"), they use XP Pro even if your installation (and license) was XP Home.

Then you sit with WGA hassles, and a very messy path to clrean this up.

My daughter's computer was infected with a search links redirect so that when she clicke on a link in Google it would take her somewhere else. We tried everything we could to remove it (MWB, SuperAntiSpyware, Spybot, etc., etc) and none of the could fix the proble.

The Avira Rescue CD found one file and renamed it and the computer would no longer boot. A windows XP repair install and 2 service packs later + the re-installation of all hardware drivers and the computer booted up and the Windows version of Avira caight a file called pci.sys.xxx and quarantined it. That was the infected file that I could not get rid of when Windows was running and it was the file that the Rescue CD had renamed.

I tell you all this because I could have saved a lot of time if I had scanned with the rescue CD first to see what file was infected and then scanned to rename or remove it and then used my Windows install cd to go to the command console and restore that particular file.

That would have saved me hours worth of work but you live and learn.

Are all files really being scanned? If you make a user private in XP or give them a password you cant browse the drive if you connect it to a host PC via a USB converter.

I have used UBCD4WIN several times before with great success. Bootable Rescue CDs have been a system saver on numerous occasions. Excellent list of available options, Michael.

Check out Trinity Rescue Kit (TRK). It contains several AV and Malware tools in one kit and most can be updated online. TRK can be made as either a CD or bootable USB drive. It is not easy for a beginner as it is all command line driven. Definitely print out the manual before hand.

The comma after, "Before,.." -- I took it to be the "oops" you were talking about.

Two other things: (1) Yes, I'm reading closely with great interest, and (2) 'splain to folks your insistence that I do this.

Thanks for the correction.

Great article and wonderful comments! Information such as this is so very beneficial to all. Thanks so much!

A good option is to make yourself a UBCD4WIN, it uses diverse malware scanners which you can update before creating the CD, and again before you need the scanner (that definition of course is lost at next reboot). This tool includes many other free tools like registry editors etc which will often come in handy.

http://ubcd4win.com

It is another good choice.

Is that it doesn't update over the Net. You have to burn a new copy before each job, this isn't a problem for me but here Michael specifically said that he wanted to list Rescue Cd's that don't require reburning.

However I've found the UBCD4Win to be an excellent choice and it's part of my tool kit along with the Trinity Rescue CD, F Secure, Avira Rescue CD, Ubuntu Rescue Remix, and Bit Defender. I don't rely on just one when I have a nasty one though I do prefer to start with the latest version of UBCD4Win then the Trinity Rescue Kit.

The bigger guns get pulled out if I need to dig any deeper.

Col

I would like to hear your thought on the AVG rescue CD or if you could try it some time and get back to us. You see more action than I do in this regard.

I'm certainly no expert on these things I just Muddle my way through problems as I hit them, unfortunately way too often for my personal liking. These problems are very time consuming to cure and I personally prefer to clean the systems and then save any data before wiping and reloading/reimaging if I'm given the chance.

But I haven't used the AVG Rescue CD so I'll add it to the list and give it a go.

Col

From reading your many musings, I feel otherwise and am fortunate that you comment on my work.

That said, please let me know what you think about AVG. Members seem to be all over the map about them.

Hello HAL 9000,

Would you mind offering more info as it relates to UBCD4 not updating over net? Are you using Ethernet or wireless connectivity that's failing to update? Which specific viral tool are you using from UBCD?

Thanks,


bremc

I would venture to say that it might also be that not all hardware is supported by the UBCD4Win. I've had instances where it has not updated because it did not have drivers for the specific hardware. Workaround for this is to either use D-Link's USB-Ethernet adapter or a generic Realtek NIC (I carry both with me always).

The burnt Copies do not update over the Net like for instance F Secure do You need to make a new Disc before you go out to a job to use the cleaners so when you go into the Build Option you can update the Cleaners before going any further. Or at least the cleaners that I use like Malware Bytes and so on.

With the UBCD 4 Win I always burn a new Disc before going to a new job and I tend to not bring the burnt Disc back after I finish that particular job.

Maybe the UBCD4Win has changed with any recent changes as I've had this copy for a while now and have got used to making a new Disc whenever I get hit with one of these jobs. I don't know but the version that I'm using works very well but it's different to some others like the Trinity Rescue CD which is a burn once and use forever or in my case till I loose it, as it updates the Definitions over the New well the wired connection and loads the updates into the created RAM Drive that is lost when the system is shut down. Not too sure about WiFi Drivers or how well this one works with them as I don't use WiFi all that much.

Col

and do agree it is a great tool to have in the kit. By the way I'm on my final setup of what I've wanted for some time. I have a 32GB stick which I've loaded with all sorts of ISO files of live CDs like we're discussing in this thread. The stick is setup to boot using the Pendrive method and will try to use the PLoP disk to help boot up the systems that refuse to boot straight from the stick.

And have been impressed so far. It allowed me to boot a very old notebook.

I've been setting up my latest USB 32GB with Pendrive loading it with all my CDs and DVDs and having a PLoP CD handy for PCs/laptops as you mention that won't boot a USB. So far I'm enjoying. It does take a bit of setup of the Pendrive list as older CDs must be updated there in order to boot and have begun adding more that are not on the list, such as the CDs you have listed and some others mentioned in this forum. Also have a folder with my own tools that sometimes are necessary for troubleshooting, testing, installing, etc.

Most of these options sound great until you get dirty. I am now realizing the PLoP CD has to be rebuilt more than I thought. So definitely not the answer.