Linux

Rescue CDs: Tips for fighting malware

Using rescue CDs to ferret out malware is a great idea, in theory at least. Getting them to actually work is another story. Don't make the same mistakes I did.

Using rescue CDs to ferret out malware is a great idea, in theory at least. Getting them to actually work is another story. Don't make the same mistakes I did.

-----------------------------------------------------------------------------------------

Malware is sophisticated enough to manipulate the host computer's operating system to help it hide. That's why rescue CDs are becoming the go-to malware detection and removal technology.

What is a rescue CD

Anti-malware rescue CDs are bootable operating systems that take control of a computer's hardware. Since the computer's operating system is inactive, so is any installed malware. That's where we get the upper hand; malware can't activate any defense to avoid being detected by the anti-malware program installed on the rescue CD.

A stumbling block

Before I present the rescue CDs I reviewed, I want to point out some mistakes I made when using rescue CDs. One embarrassing mistake happened during a visit to a client. It was the wrong time for me to realize that certain versions of rescue CDs require a new .iso file to get the latest signature definitions.

After that oops, I made sure I used rescue-CD applications that can download and incorporate the latest signature files without needing to rebuild the CD.

That brings me to my next mistake. I typically don't give much thought to whether the network connection is hard-wired or Wi-Fi. I assumed rescue CDs would be able to update using either. That's not always true. In some cases, rescue-CD apps will not recognize the wireless network adapter.

Here they are

The following rescue-CD applications always get good reviews and do well in independent testing. And, they are all capable of updating their signature database via an Internet connection:

AVG Rescue CD

Base: Linux (77 MB)

Configured to create either a bootable CD or USB drive

Signature Update: Online update or downloaded signature file

Avira AntiVir Rescue System

Base: Linux (47 MB)

Signature Update: Downloaded signature file

BitDefender Rescue CD

Base: Linux (228 MB)

Signature Update: Online update or downloaded signature file

Dr.Web LiveCD

Base: Linux (65 MB)

Signature Update: Online update

F-Secure Rescue CD

Base: Linux (155 MB)

Signature Update: Online update or downloaded signature file.

Kaspersky Rescue CD

Base: Linux (103 MB)

Signature Update: Online update

Norton Recovery Tool

Base: Windows Vista PE (241 MB)

Signature Update: Online update

Best at detecting malware

Avira's AntiVir Rescue System is consistently on top when it comes to malware detection. Virus Bulletin is a well-known test house for anti-malware, and they place AntiVir Rescue System first (registration is required).

A close second is BitDefender Rescue CD. To many system admins being second is not an issue. That's because BitDefender Rescue CD has many attributes that make their job easier.

Most features

BitDefender Rescue CD outclasses the entire group when it comes to features. That's in large part due to BitDefender using Knoppix, a well-thought-out Linux distro. It has many third-party apps such as ChkRootKit, Nessus Network Scanner, Partition Image, and GtkRecover. One additional convenient feature is the inclusion of the Firefox Web browser.

Create a rescue flash drive

Most rescue CD applications require converting an .iso file to make a bootable CD. If that seems confusing, this link to the Petri Web site will help explain. With netbooks becoming popular, using a rescue CD isn't an option. One way to resolve that is to use UNetbootin. It is an application that will create a bootable flash drive from any of the above rescue-CD .iso files. I have to admit though, it's a cumbersome process.

Thankfully, AVG Rescue CD has an alternative answer. Simply download the rescue file specifically developed for flash drives, extract the contents of the file to the flash drive, and click on makeboot.bat. That's it. You now have an AVG Rescue Flash Drive.

OS boot sequence

One other consideration that needs to be addressed is the boot sequence of the computer being worked on. If you are using a rescue CD, the CD drive has to be moved to the top of the list. If you are using a netbook, more than likely the USB drive will already be first on the list and not a problem.

My rescue-CD wish list

Many things have to go right for rescue CDs to work. It doesn't have to be that way. All it would take is the following:

  • Make it simple to create "rescue flash drives." Why? They can be easily updated without involving access to the computer's operating system or having to recreate the CD.
  • Make sure the BIOS software recognizes USB drives in their boot sequences.
Final thoughts

Rescue CDs and rescue flash drives will become more important as malware writers figure out better ways to obfuscate their code. Rootkits come to mind as they are the forerunners of deception.

If you prefer a rescue-CD application not listed here, I would appreciate learning about your experience.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

220 comments
computerA+noob
computerA+noob

Hello, I happen to find many of the rescue disks have errors or don't work at all. Dr. Web, tried many times on many different computers, and kaspersky has never worked, I get the main green screen and then it just doesn't do anything. I have tried on all platforms of windows and several different manufatures of computers. So what's the deal. Have they stopped making them. Have they gone the way of Norton which you have to have a code? It really annoying. Also on some of them when you do a download it asks you were to place the download? I have no idea. How do you find out where the proper place to put the download in is. I would like to use these types of boot CD's more often. Right now I find Sardu to be very good as it offers several downloadable antivirus boot cds. Though when they don't work I go to the main website to get the download, and find it doesn't work there either. What's up with that. Any idea what I am doing wrong

ken
ken

You forgot to mention that Norton will ONLY work if you have one of their antivirus or internet security installed, as it asks for the PIN number or Product Key number. Therefore NORTON gets a MINUS 10 from me.

Vern Anderson
Vern Anderson

UBCD4WIN.com these guys assemble all the best freeware tools for you and they write the tool for you that helps you build the CD/DVD and even USB pen drive. You just need a valid Windows XP CD.

HAL 9000
HAL 9000

a play with the AVG Rescue CD on a couple of different systems. By no means a definitive test but it looks OK provided that you don't have a Intel Chip Set Video Card. On 3 systems with Intel Video all relatively newish I've been unable to get any sort of usable display but with NVidia and ATI Video it works a treat. I did notice a few False Positives with EXE Install Programs but otherwise it cleaned up the systems and worked quite well. Col

cquirke
cquirke

It's no longer possible to reply to ocie3's posts where they occur, so I've started a new thread here. This isn't about Rescue CDs per se, but on-topic for "fighting malware", so maybe Michael Kassner won't invite us to leave :-) Perhaps we should take this to email anyway, as it may be of limited interest to other readers and may get into territory I prefer to keep less public. What ocie3 describes is something that adds code to existing executable files on the hard drive (which I'd describe as an "intrafile code infector"), and that persisted or recurred after the first attempt at wiping and rebuilding the system. The methods used to wipe the system look solid to me, and the rebuild process looks fairly OK, too (though I'd install XP SP3 and IE8, and apply passive Spyware Blaster and Spybot immunity - Restricted Zone and HOSTS black-listing - before going online). All other drivers and software was installed from original read-only media (hopefully, before going on line) and only "data" was restored. I assume he's operating through a UI set to show all files and .ext, so that he doesn't miss hidden .doc etc. and mistake visible icon-spoofing .doc.exe for these; in any case, he implies the data was scanned via multple av before the restore. He says he's suppressed \Autorun.inf risks from storage devices (whatever was used to source the data backup comes to mind), and I hope that involves more than NoDriveTypeAutoRun and/or NoDriveAutoRun flags on a baseline XP SP2 code base. A further patch is needed before NoDriveTypeAutoRun=FF is actually honored by the OS, and I'd also prefer to use legacy .INI redirection to divert Autorun.inf to oblivion. So, if we're clean this far, then the malware must have persisted at the PC BIOS level, which is unlikely, or re-entered from the Internet, other systems on the LAN, USB storage devices etc. and a possible factor may be hacks to the router that redirect DNS, or (less likely) direction from there. Else it may be as ocie3 suggests, that a web site trusted to run scripts in Firefox may have re-asserted the infection. It's certainly "interesting" enough to warrant retention of forensics, e.g. keep an original hard drive (perhaps formally enough for legal purposes) as this smells like it will be back. His description of what happens to existing .exe files sounds more like a file infector than in-memory intrusion, which he says is excluded by firewall/HIPS defences. Just as well, as a pure in-memory patch-in that doesn't write itself back to disk, won't be forensically visible on the retained hard drive. As to integration points, there are a horribly large number of these at the design level, and more below this at the level of code exploits. Web browser plugins and .DLLs wrapped in SVCHosts and RunDLL* are hard to spot as processes, as they show up only as the wrapper; this may also sneak them out through the firewall. The same problem may apply to ADS infectors, as these are seen by Task Manager (and perhaps firewalls) as the base stream of the file to which the ADS is attached. This file will of course pass the MD5 content check, which didn't happen (well, not the first time, at least) on ocie3's case. Suspect the ADS factor if you find processes like "ReadMe.txt" or "System.ini" running in Task Manager :-) If you avoid NTFS, the ADS problem goes away, and you can still do that with XP. ADS also don't persist when submitting files to online scanning sites (the only way I'd use these(, but it sounds as if his code infection was within the file itself (thus breaking MD5 checksums etc. and alerting firewall/HIPS) and thus such submission (as well as your own FC tests) would be a good step.

cquirke
cquirke

Managing boot order is constrained by various BIOSs, and a "gotcha!" is where certain keystroke conventions work, but aren't undoable. For example, sometimes you can use Shift+1 to suppress a boot device, or X, and in some cases these keystrokes work in one direction, but not the other! I prefer PCs to boot hard drive before anything else, and ideally not boot anything else. This gives the best protection against malware'd removable storage (currently uncommon, but could recur); it also acts as a bozo filter for low-skilled techs who are likely to do more harm than good if they could boot the OS installation disk (I don't apply password to CMOS Setup, so it's not an unreasonable speed bump). From that starting point, first prize is a POST hotkey that brings up a menu of devices from which to boot, just for that session. If there isn't a boot device menu hotkey, then you have to go into CMOS Setup to change the boot order, do the job, then change it back when done. Ideally you want to make it impossible to blunder into booting the stricken hard drive, but while most modern BIOSs let you exclude devices from the bootable list (I usually exclude USB and Network, leaving optical and diskette as enabled, but behind the internal HD) it is rare that you can completely disable hard drive boot. One "gotchas" here is that some boot CDs and DVDs "fall through" to boot the hard drive if you don't "press a key" within X seconds. Windows installation disks do this, WinPE defaults to this (though you can change that in WAIK), and Bart can be set to this too. Another "gotcha" is that some BIOSs will boot devices not listed in the boot order, if none of those have worked. So if you have been able to remove the hard drive from the boot order, look also for a setting to "Boot Other Devices" and kill that, if found. It's particularly important to prevent the hard drive from booting if it is in a different PC to be "treated", else the installed OS may tie itself up in Plug-n-Play knots and/or invalidate its activation status. You'd be luckier if it had just BSoD'd, as XP usually does if you change the ACHI setting in CMOS. If you're running an unattended RAM test such as MemTest, you don't want this to automatically reboot if the PC spontaneously resets (even though that is far safer than booting the hard drive by accident) as you may miss this; you may see "no errors, still running, good" whereas perhaps it's reset itself several times already. That's why I tend to use the MemTest in Ubuntu boot disks; that way, they sit on the Ubuntu screen if the PC resets itself.

cquirke
cquirke

Where do you download BitDefender Rescue CD? The link in the article leads to an "about" page with login prompt for registered users. Back-tracking to the "front door" of the site and forward from there, leads to downloads, and a page of freebies and another page of malware-specific cleaners, but no Rescue CD. So far, I've downloaded, built, and am testing Avira, Kaspersky, AVG and Trinity Rescue Kit. AVG is *very* easy to use, mainly because they've designed the UI as a well-thought-out wizard; Avira and Kaspersky pretty easy too, but sometimes you have to do a few manual things like checkbox the drives you want to scan, via their unfamiliar Linux names. Trinity Rescue Kit is a different ballgame; you boot to a raw Linux command prompt, and have to smell your way from there. Good luck with that, given how difficult it can be to simply find a text editor in an unfamiliar Linux... "notepad? edit? Edit? Er... gedit? aedit, bedit, cedit..." where the answer may be "It's gfeditplus, because in 1997 Gary Fredricks developed a great new editor and Fred Blob enhanced it to the Plus version but wasn't allowed to name it fbedit for some arcane political reason". Well, that's Linux for ya :-)

Snuffy09
Snuffy09

does malwarebytes have a rescue cd?

kurtesmaximus
kurtesmaximus

Been doing this for a while and I've had pretty good luck with Trinity Rescue Kit and Knoppix. I do intend to check out BitDefender and F-Secure next chance I get. Check out the F-Secure blog if you haven't.

Michael Kassner
Michael Kassner

I will pass that info on to AVG. Do you think it's just lacking the correct drivers?

Ocie3
Ocie3

Although I believe that I've seen your handle before ([i]cquirke[/i]), I doubt that you are a regular participant in discussions here. If you were, then you would surely know even more about the odyssey with the "undetectable rootkit" than I have disclosed in our discussion. Certainly, I kept notes about most of it, but not a daily journal, because if I had spent the time and energy to keep both, then I could write a book. ;-) The saga would, of course, be a historical account. The TCP/IP packet [i]outbound[/i] from a closed port that was dropped by Sunbelt Personal Firewall was logged on June 3, 2008. Norton AV 2005 with current definitions, Spybot Search and Destroy (ditto), and the firewall were running. A Linksys WRT54G router was, and still is, between my computer and the ISP's "DSL modem". But my computer was, and still is, the only device on the "LAN". Currently, I'm running Sunbelt VIPRE Premium 4.0, an AV with a firewall incorporated into it, but not exactly the same one which they bought from Kerio and renamed "Sunbelt Personal Firewall". Can't say that I recommend it since I'm looking for something better (see also the footnote at the end of this post). The first nuke-and-reinstall-it-all process was during the first week of November 2008. I will spare you the details of that one and of each one since. Suffice it to say that the "undetectable rootkit" usually became manifest within 24 to 72 hours after I had completed each reinstallation, [i]i.e.,[/i] after I had resumed online activity. The most recent nuke-and-reinstall procedure was in mid-April 2010. At the time of that first event, and many observations that followed, the anti-malware software, methodology, and tools which I found available [b]to me[/b] were not the same as today. So many things that you have mentioned as possibilities or as routine and common, whether with respect to malware or with respect to finding it, were not widely and commonly seen as such then (not only by me). For example, although I already had a BartPE bootable CD and it has some useful software on it, it didn't have much that was useful with regard to finding malware. I probably built it some time after SP2 was installed, and the options today are much different. So, if the text on the UBCD4W web site looks staid and old, that is how it looks now, not then. Today, it seems that everyone and his dog has a "Rescue CD" or two dozen somewhere on their person. Or maybe that is a "flash thumb drive" (5 GB!) in their pocket. When I bought the computer, it was offered with a mainboard which had USB 1.50 ports. For $50 more, the system integrator replaced it with one that had four USB 2.0 ports (the latest) and some other better features. In 20/20 hindsight, I should have spent another $50 for Windows XP Pro instead of just $100 for Windows XP Home Edition, but I did not expect that I would ever need the additional features. Though I bought the 320 GB USB Maxtor One Touch 4 in September 2008, for backing-up data files, I did not attach it to the computer until this past January. Simply, I feared that the "undetectable rootkit" would find a way to use it to re-install itself on the internal primary HDD. After I read an article on Icrontic titled "Reformatting Windows XP the Right Way" (http://tech.icrontic.com/articles/reformatting-the-right-way#loads_desktop), I decided to use the Maxtor during the next nuke-and-reinstall. But I modified their process a bit here-and-there in the light of what I had learned from others and from experience. (I also bought a 160 GB Western Digital Caviar Blue HDD to replace the aging Hitachi HDD that was in service for over 7 years.) It did not help matters that I did not start out knowing nearly so much about PC system security and malware as I have since learned. It has been a long trek through many forums and web sites, many searches, and much reading. As I've said before, I was "dragged kicking and screaming into the battle with the malware criminal gangs". However, it eventually seemed more likely that the malefactor was simply an ordinary, old-fashioned [b]sadist[/b]. Every investigator (of every stripe) should always bear in mind Ockham's Razor. So far, I've learned enough to begin to perceive the abysmal depths of my technological ignorance. Specific points: * All files are displayed by Windows Explorer regardless of attributes. Oddly, the Search feature reports a desktop.ini file in C:\ and in C:\Windows, respectively, but Windows Explorer doesn't display them, neither are they displayed by the Windows XP [i]cmd.exe[/i] directory command (Command Prompt). * Regarding autorun/autoplay, I will post a reply to your remarks in the post on this thread about Removable Drives. However, I've never detected an autorun.inf file on the USB Maxtor HDD or on any CD-R/W that my computer has created that was not supposed to have one (and I have always examined the content of those). * SP3 was released in April 2008. Despite Microsoft's insistence that Windows XP Home Edition users should [i]not[/i] download the .ISO, I did so and burned it to a CD-R/W that I still have. I used it in all of the re-installs except the most recent. * I've been using the mvps HOSTS files for years. The problem with such a large file is that we need to make a cryptographic hash for it, then do it again once in a while to compare the most recent to the original, in order to detect changes that something has made (other than any that we have made ourselves). The mvps HOSTS was updated on June 10, 2010, the first time in six months, AFAIK. * There hasn't been anything to indicate that the malware has altered or been loaded into the BIOS. * There are no other systems on the LAN, nor have any USB storage devices been present while the malware also was evidently present until just before the nuke-and-reinstall in April 2010. * Wireless access through the router was disabled at the time that the malware became evident and has remained so since. There hasn't been anything to signify that the Linksys WRT54G router has been "hacked". For a while, I enabled the DHCP server and specified DNS servers. Then I disabled the DHCP server and resumed specifying the DNS servers in the Properties of the Local Area Connection. "Re-entry from the Internet?" Certainly, especially if the undetectable rootkit was installed by a hostile employee or agent of a "friendly" web site who had access to the web site pages and knows JavaScript well. [b]It is quite telling[/b] that there hasn't been any evidence of the presence of that malware since the most recent nuke-and-reinstall-it-all in April. And Firefox has not fetched a page from that web site since February 16. Sometimes I am tempted to revisit that web site, but, essentially, only Sandboxie would be interposed between my computer and any malicious activity that might occur. There are many other things that I need to do with my time and energy than research malware. Your remarks have been interesting and enlightening, but I think that you can take a break, now. :-) ____________ [i][b]Note:[/b] As far as I know, Sunbelt Personal Firewall is no longer available for public distribution. Although most of its features were incorporated with the AV into a single program, Application Behavior Blocking (which functioned as a simplified "white list") was not included. To have the same intervention when an "unknown program" attempts to run, a separate whitelisting system is needed.[/i]

cquirke
cquirke

It can be a bit confusing, the ways in which drives are considered "removable" or not. It may be obvious to the user that a drive is physically outside the case, or contains a separate and ejectable medium. But with internal motherboard USB sockets and eS-ATA, things may get very blurry for the OS. The OS needs to treat these differently, in that a removable drive shouldn't be considered part of the system. Ideally, it should be handled with fire tongs as high risk, but that awareness isn't present in the OS, which is quite happy to integrate code on even the most obviously removable drives. Even if the target code is safe, trying to access it every time a certain file type is displayed, or whenever the shell "blinks", is likely to bog down performance. The OS may consider a drive "fixed" if it's present at boot, if the BIOS and CMOS Setup say it is of fixed type, or if it contains a hard drive style partition table and MBR. I don't know which of those cues dominate, or even apply. What I do notice, is that flash drives and SD cards are usually treated as "removable" (no Recycle Bin, no SVI subtree, not auto-enabled in XP for System Restore) while external hard drives are usually treated as "fixed", even if these do show a Safe To Remove UI when connected. In fact, it's disturbing to see modern Windows showing "Safe To Remove" UI for the internal S-ATA hard drive, in some cases. If a drive letter shows a "funny" icon, that effect suggests an \Autorun.inf has been processed, and you may want to avoid that. This applies to hard ("fixed") drive volumes as well, and can cause ?hostile code to be launched when navigating into that drive letter. NoDriveTypeAutoRun has a bit flag for each type of device; if set, it is supposed to suppress \Autorun.inf for that device type. But Windows older than 7 fail to honor that setting unless patched, and the process and documentation around this has been slow and murky from Microsoft's side. A USB storage device would logically be treated as a "removable drive", unless seen as a hard drive, or is spoofed by U3 to be treated as an optical drive. Win9x used to default NoDriveTypeAutoRun to 95, which suppresses removable drives; the XP and later default value is 91, different only in that removable drives are now enabled for \Autorun.inf - strange, that.

cquirke
cquirke

A Desktop.ini file can be dropped into any writable network share, so one really hopes Windows isn't dumb enough to launch code in response to what can be in there. In XP, there would be a Desktop.ini within certain shell folders, where they may back-link via CLSID to behaviors appropriate for that type of "special" folder. They are also used to change displayed folder names, so that there can be a consistent "real" name across different human languages, while displaying a name that is appropriate for those languages. They are also used to show the shell folders of the logged-in user as "My..." instead of the explicit user account name. A Desktop.ini may also be added if you customize a folder, e.g. specify a different icon to be displayed. Unfortunately, modern Windows spawns Desktop.ini files at the drop of a hat, often during copy operations (which is why you may see an overwrite warning when copying to a truly empty folder). Autorun.inf can do the same things, but more so; code can be set as the new "open": action for that folder, other actions can be added or redefined, etc. Fortunately, AFAIK this works only in the root folder of a drive letter, and there are ways to suppress these risks. So far, malware has used Desktop.ini mainly for the Recycle Bin CLSID's ability to hide files within the folder, and show what's in the Recycle Bin instead. In all cases I've seen so far (and it is now a very common technique), the icon remains that of the Recycle Bin. Kill the offending Desktop.ini, and the effects clear; icon changes back to default, actual folder name is shown, contents are shown as far as the shell's UI settings alow. You may have to refresh the view to see this, however. If you can search and list all Desktop.ini (which are usually set to be hidden via their file attributes) then you should be able to search the contents for the Recycle Bin CLSID, which AFAIK is consistent, at least within the same version of Windows. That will de-bulk the mass of them that you'd need to chase further.

cquirke
cquirke

It's unusual to find a "classic" code infecting virus that exists purely as such, but some recent ones do exist. More often there will be a larger "mothership" malware stand-alone file that interacts with small stubs within infected code files; these may launch the mothership's code, maintain the infected state, or spread the malware beyond the system. The first point of entry may be a tiny downloader agent that is often found in Temp or web cache space, which is why I move the contents of these locations "from orbit" and retain this material until the next malware checkup (in case updated sigs find stuff that was missed last time). These downloaders are likely to mutate often, as they have to operate before the system's defences can be suppressed, so as not to be detected; once the real malware is in place, that may delete the downloader to avoid it being sumbitted to av vendors. All that is needed to re-infect the system, is a downloader of this sort, an exploitable surface to allow it entry, or a footprint within re-used off-HD material. None of this requires rootkit functionality as such; that can be pulled down later. If the agent is within a legitimate but infected code file, or hidden by a wrapper such as RunDLL*, SVCHost or a web browser into which it is plugged, it is likely to be allowed Internet access to pull down the rest of the malware load.

cquirke
cquirke

AFAIK MalwareBytes doesn't have a rescue CD product, and may be unsuitable (unsafe) for use in such environments. It's been a while now, so my memory has lost the details, but what I remember was an issue where MalwareBytes would automatically "fix" some settings that broke bootability, and get this disasterously wrong when the expected drive letters didn't line up properly. So if you'd integrated it into Bart, for example, which boots as drive X:, it may "fix" "incorrect" paths for key boot files by changing them from C: to X:. Then the next attempt to boot the hard drive falls on its butt. Specifically, the filespec that was changed, was the Userinit.exe line in the registry. Whether it would be able to "see" that natively, I don't know, but as I'd normally wrap registry-aware (but not off-HD-boot-aware) apps in RunScanner, that would be a serious and very real risk. I think with MalwareBytes, it's a case of "we don't have it, so you don't need it". Given that it's a free tool, and developing a Rescue CD solution is difficult, I'd say fair enough - but that puts them in second-tier status for me.

d_g_l_s
d_g_l_s

install into the windows system/registry in order to work/operate. So this means it would have to be installed into a Windows-based PE of sorts.

Michael Kassner
Michael Kassner

I looked at Trinity, but I try to give credence to applications that are user-friendly. For instance, how AVG Rescue CD works. I know Trinity is a great deal more powerful, but most will avoid it for that very reason.

HAL 9000
HAL 9000

But I didn't get a Display at all not even the Menu System at the start of the Disc. I just checked a MSI L720 which has Intel Video and it worked fine on all modes this week so I would tend to think that it's related tot he Hardware in the other systems. Yep been a bad week and at 0600 hours I'm still waiting to get some sleep which may happen next week sometime the way that things are going at the moment. I've thrown this Disc at a few more systems since the above post and didn't run into any problems. Which is good because I just couldn't handle them right now. :^0 Col

wyattbest
wyattbest

As someone who has been reading your threads with cquirke with great interest, the primary question in my mind is, "What website??" I know you said you have not visited it since Feb 16, but 5 months later it might be possible that it is still there. I'm guessing that it's something of a, uh, personal nature, but I'm sure that there are at least a half-dozen people here who would promptly try to reproduce your symptoms with better tools to unshroud the mystery. If this mysterious chunk of code exists and is still out there, it would be good for the internet at large to capture and expose it.

Ocie3
Ocie3

FWIW, I've found various instructions, only to find that some evidently do not work and others may contain typographical errors, so they won't work either. Following is an excerpt of text that I collected from http://antivirus.about.com/od/securitytips/ht/autorun.htm . I have the date 2010-04-07 in the file, but that is probably when I made it: [i]"9. XP Home users will need to make the changes by editing the registry directly. To begin, click Start and then click Run 10. Type regedit and click OK. The Registry Editor window will open. 11. In the left pane, navigate to: HKEY_CURRENT_USER Software Microsoft Windows CurrentVersion Policies Explorer. 12. With Explorer highlighted, in the right pane (sic.) right click the value NoDriveTypeAutoRun and select Modify from the drop down menu. The base value will be set to Hexadecimal. If not, select Hexadecimal. 13. Type 95 and click OK. Note that this will stop Autorun on removable/USB drives, but still allow it on CD ROM drives. If you want to disable autorun on both, substitute b5 for the 95. (Thanks to Ian L. of Manitoba for the tip). 14. Exit Registry Editor by selecting File, then choosing Exit from the menu. 15. You will now need to reboot your computer for the changes to take effect." (italicization added)[/i] My own note in the file: 95 causes the Autoplay feature to run endlessly on a DVD or CD drive as it searches for an autoplay.inf file that does not exist on the optical media that is in the drive. Apparently, Windows XP does not like the hexadecimal value "b5" because the current value of NoDriveTypeAutoRun is 0x00000091. What I wanted to do, of course, is disable autoplay/autorun for both USB devices and the DVD and CD optical drives. Do you have any suggestions?? __________ [b]Update:[/b] I have set the value of that key to 0x000000ff and it survived the system reboot. Dunno yet what will happen if I attach the external USB Maxtor HDD or insert a CD-R/W disc into the DVD or CD optical drive.

Ocie3
Ocie3

I thought that the malware was probably a "classic virus" that had escaped detection by Norton AV 2005, and because of its activity revealed by TCP View, it appeared to be a [i]worm[/i]. In fact, I had never heard of a "rootkit" on a PC system (only on ye olde mainframes), nor knew anything about the possibility of an "undetectable rootkit", until I visited the Sysinternals web site. The "tiny downloader" must be executed in some way, usually at the time that it is introduced into the system. That does not happen automagically just because it is present. For example, "drive-by downloads" happen because the malefactor's web site uses JavaScript to "drop" such an executable on the hapless "visitor's" computer [b]and[/b] launch it. Also, a lot of malware is launched unwittingly by the computer's user. No doubt that we could compare long lists of ways for malware to successfully invade a computer system. [i](deleted reference to TechRepublic article, since I could not identify it properly)[/i] That said, if it was a "classic virus" of the kind that you describe, then it seems to me that at least one of the 20+ antimalware programs that I ran over the course of the first eight months or so would have detected and identified either the "downloader" or, more likely, the "mothership" or other components of the malware package. Also, performing a nuke-and-reinstall-it-all will indeed completely destroy any malware that is installed on the subject computer. Period. But within 24 - 72 hours, it would become evident that the computer was infected by a malware process [i]again[/i]. Of course, the first thing that I had to consider was whether the malware that became evident after the nuke-and-reinstall was the same malware that was eradicated by that process. Given my observations of its behavior, it was quite likely either the same malware or perhaps an update or other variant of it. The question then became, if there is an evident "re-infection" by the [i]same[/i] malware, then how and why is it occurring?? For a while, the only answer I could find was "probably the same way that it was installed the first time". Regardless, it doesn't particularly matter whether an "undetectable rootkit" was downloaded and installed [i]subsequently[/i] by a "classic virus" which was the primary intruder. Remember Ockham's Razor: when there are two or more explanations for observed phenomena, then the simplest explanation is the most likely to be correct. An undetectable rootkit can be installed without involving a "classic virus". When something that nothing can see is running on a computer, then why is it invisible?? And I don't mean just invisible to 20+ AV scanners, but also to programs such as Sysinternals Process Explorer and Process Monitor, among others. [b]Postscript[/b]: Upon further consideration, including some specifics that I observed, it [b]is[/b] quite likely that the initial intrusion was by a "classic virus", probably a modified worm. Once it was established, it installed the rootkit installer with the kernel-mode driver, which would hide the initial intruder and the rootkit files, too, of course. The reason that I have reached this conclusion is that some malware executable(s) had to be making the connections to other computers [i]via[/i] the Internet, and corrupting the other executables which were stored on my computer. The program which installed the kernel-mode driver during each system boot was probably not doing anything else.

cquirke
cquirke

Thanks; downloading now! It's a testimony to Linux maturity that not one of the scanners I tested (Avira, AVG, Kaspersky, F-Prot, Dr Web and the inscrutible Trinity Rescue Kit) has failed to boot, or crashed while scanning, as tested on two PCs with plenty of files to scan. BitDefender and Panda still to test. Most or all of these don't update the ISO with current av signatures, but will accept these via USB and/or live download. I prefer the USB option so as to reduce online bandwidth and risks; YMMV. My other test criteria, are: - are fresh ISO downloads up to date? - can updates be read via USB? - can updates be downloaded "live"? - direct CD boot, or fall thru to HD? - must I set anything before scanning? - are they safely read-only? - do they auto-fix malware? - if so, can that be controlled? - USB-booted versions instead of CDs? - do drivers work with my Ethernet? - do drivers work with my WiFi? - how easy to use? - how easy is it to save the logs? - do they come with other useful tools? - is the rest of the Linux OS available? - can I use these regularly? Also nice is that all downloads were quick and trouble-free; no scratching around with torrent clients etc., as may be inevitable with large "goodwill" projects.

d_g_l_s
d_g_l_s

Live CDs but still within the realm of security, what are your thought on the new Panda Cloud Antivirus Free Edition 1.1 that Techrepublic has just brought to our attention?

Neon Samurai
Neon Samurai

The retail applications are on the Hiren's disk but I believe it presents a message during boot or when you run one of them that says "this will run from the disk but please only run it if you own a license for this software".

JCitizen
JCitizen

as I wasn't actually meaning to point to those in this example(although the Apple incident was). I was talking about rootkits or other malcode that can do just that. Since I've never been able to correct drive geometry problems without a factory utility, I assumed that may be the only software that takes direct control of the drive(controller), to correct any faults, including the already mentioned hidden, or fake hidden sectors. I realize I'm working with a lot of assumptions, but I've done enough recovery operations with bad drives that I feel like I have some good instincts with this. My 30 years in the automation repair business, also gave me good instincts on what makes hardware/software tick. But, that is all I have to go on - not scientific fact. TR has several articles on these type of attacks, I'm pretty sure Michael was in on one of them. I just do a search on the TR console when I have time to. Sorry I don't have the links. HAL is on the right track about what I'm talking about.

HAL 9000
HAL 9000

It embeds itself in Sectors of the HDD reported as Dead. When you run a Utility Like Boot & Nuke or Kill Disc it ignores the Sectors Marked as Bad so the infection survives. The only solution is to do a Low Level Format which used to be possible in some old BIOS but isn't all that available now days. I however may be wrong in my understanding of this I haven't personally experienced it. ;) Col

d_g_l_s
d_g_l_s

come to mind... 1. how would a virus/trojan prevent itself from being removed/overwritten by a drive wipe program, especially one run from a Live CD? 2. how could a virus/trojan "reinsert" itself into the new OS when the OS get's installed over a wiped drive? I'm looking for reasonable answers here. In fact I'd like to see some links or posts and even be able to connect personally with those who are claiming this happens. Pardon my skepticism but I do deal with real world scenarios all the time and there's always a reasonable explanation for everything that happens.

JCitizen
JCitizen

I will try to do a better job capturing the opportunity to get an example of this, if I can catch my newer clients in the act. The guys with the MacBooks sounded like they were pretty competent, and they were all ZDNet members in good standing. They were using LiveCDs to view the files, but I thought they said they were using the OSX installation utility to format the drives, but I can't tell you for sure the folks using DBAN are reliable informational sources. The articles I've read on the subject claim this does happen, but I can't remember what tools they were using to clean the drives, just what they were looking at them with after each attempt. I've added you as a contact, so you should be able to contact me directly through the TR site. I get emails from other members this way. Obviously I don't publish email addresses, because of data miners.

d_g_l_s
d_g_l_s

on this. I'm not surprised it's linked with Limewire as I've had many runins with it being on the system and causing malware headaches. I warn my clients and try to discourage them from using it by explaining how they are basically causing their PC to "kiss" every other PC with Limewire out there and so can catch the "kissing" diseases :) Most are thankful for the heads-up and take action from there. I'm a bit surprised that DBAN and the likes would not clean the surface. Has this been confirmed that this is actually the case? I don't like rumors in place of facts. Unless they are somehow using a CD run DBAN or floppy which is infected as well or there's an attached drive with infection or the BIOS is infected. Would sure like to get to the bottom of this before it happens to one of my clients. Can we keep in touch? And if valid let's let Michael Kassner know as well. Thanks, Doug

JCitizen
JCitizen

are reporting this. One of them said he had a bunch of MacBook users that caught something on limewire, and after nuking the drive, the drive still had obvious malware files still on it. They were looking at the drive with Linux LiveCDs. I ran onto this discussion on an article about firmware infected MacBooks. Some of them had been shipped with an infection in the keyboard controller - apparently. I don't remember if it was ZDNet or Tech Republic. Same with Windows units - after nuking the drive the infection returns. Looking at the wiped drive later shows the malware files still on the drive. These folks were using Windows of all flavors, all the them had limeware on the machine before the disaster, they all tried at least reformatting, and at most DBAN to try to blow it away. I've got to assume this is how the malware is accomplishing this. My clients won't bring them in for me to try something, they just throw the PC or hard drive away. I was hoping the factory original low level formatting would do the trick, as I think I cured at least one PC of this same problem. Only I didn't look at the drive with Knoppix like I usually would have, because I wasn't suspecting infection to cause the goofy drive tests I was getting. I just assumed the newbie who installed the operating system on a amateur system build, had incorrectly set the drive geometry. After I worked it over it was fine and it is still operating - but I never looked at the drive before conditioning it with the factory disk utility. That incident was another P2P disaster.

d_g_l_s
d_g_l_s

this has happened? I've never heard of this and if does it certainly is not common. What shows it's sectors flagged for damage? I'm assuming even sectors flagged for damage can be cleared/overwritten. But I'm interested to know what you have, what OS, and what you've tried and how you came to conclusions you've stated.

HAL 9000
HAL 9000

A Image of a Fresh Install is always better as a Fall Back Option. I do it with all of the systems that I make but unfortunately I don't only work on the ones that I make. ;) Col

JCitizen
JCitizen

is how to deal with malware that embeds itself into self created disk sectors flagged for damage. What does a guy have to do to get low level formatting to write to previously flagged sectors? Flash the drive controller?

d_g_l_s
d_g_l_s

always just rebuild. Ends up being same time or less but I have clients who are either quite particular about their setups or they have lost or never had the CDs for some software they "must" have. Have developed a method of logging into Safe Mode and getting a "foot-hold" on the system by installing or using an installed version of Malwarebytes. If Malwarebytes refuses to update then I know I have to deal with the "Fake AV" and must deal with it. Usually I can stop it from preventing Malwarebytes update by running most of the RKILL executables (all of which are on my USB). Once I get Malwarebytes updated and running it usually takes care of the trouble. Then I get login normally and install MS Essentials and clean up what remains. Have a program that's supposed to allow installation of Essentials and other such programs in Safe Mode but have yet to try it.

Michael Kassner
Michael Kassner

I ran it on an infected netbook and it did not resolve the issue. So, I am still of the same mind as most TR members. Rebuilding is just the easiest way to go. If you have the insight to immediately make an image of a pristine system, that's even better.

JCitizen
JCitizen

Comodo with Defense + installed and in full force, has a HIPs that does a pretty good job warning about file manipulation, it also tries to sanbox untrusted files, but gives you the option to forgo sandboxing. I've had pretty good luck with it over the years, but had to stop using it on my Media Center, because it is so leakproof it wasn't letting my [b]"legal"[/b] DRM spies phone home. Comodo is working on the problem, but mean while, I feel naked to the web, without it. I can't tell you how many times it has prevented attacks from formerly trusted sources, and I wouldn't doubt if it weren't a good factor as another piece of armor in the defense-in-depth, to fight Zeus variants.

Ocie3
Ocie3

that if I disclosed the name of the web site, then it is quite possible that they would sue me. They certainly want to pretend that each and every service which they offer is just innocent fun, but the site is on the MVPS HOSTS list for a reason. According to an article that I read recently, perhaps in the New York Times, many web site owners and/or operators have begun suing their critics and detractors for libel, regardless of whether they actually have a case. They can be counter-sued for abuse of process when their suit is without merit, but the legal expenses to respond to such a suit with competent legal counsel are enormous for any individual. Who can afford justice nowadays? Of course, I suppose that I could reinstall the old Hitachi HDD and re-image it from a disk & partition backup, then return to the web site, perhaps without using Sandboxie, just to acquire the malware. There is no doubt in my mind that it probably would be installed again, but it could be an improved version that I would never detect. There are many possibilities which I would prefer to consider very carefully before such an undertaking. One problem is that Sunbelt Personal Firewall no longer exists, unless I can find it among the software which I stored on a CD-R/W that the drive will actually read. I've had difficulties and disappointments with doing that recently. So I need that or better software that would tell me when an executable has been modified since its most recent execution. There are utilities which can be used to create and to compare hashes of files, of course, just that they cannot alert me when such a change occurs. More thinking to do. Probably a lot more learning, too.

JCitizen
JCitizen

there was a lot of confusion among the sales people as to whether the LS-120 was an optical or magnetic device. They didn't have a clue; so my brother abstained from buying one for his Mac. Looks like it was quite the device; I wonder if the disks were as sturdy as the ZIP drives?

HAL 9000
HAL 9000

Not one of the more common ones but I saw a lot of them once. Col

JCitizen
JCitizen

I tried it from a CD on my honeypot, and it attempted to install without any intervention other than putting the CD in the tray and closing it. NIS 2009 nailed it instantly. No telling if other undefined malware installed despite this however. None have shown up, but I've done a reinstall since themnfor DRM issues, not malware. I'm still using ZIP drives, so I can help folks that have them on their PCs. It is an external one, and haven't heard the click of death yet! It is so old it connects using the old printer serial port. I would buy a lot of Zip media if they would just drop the price. I like storing data for long term storage on them rather than CDs/DVDs that can degrade over time. However, the greedy attitude of the original copywrite holder knows no bounds, so I'll just hold off.

Neon Samurai
Neon Samurai

And the Jaz drive that came after it briefly before CD and DVD eclipsed them.

Ocie3
Ocie3

Since Belarc Advisor reports that all Windows XP patches & updates are installed on my computer, it follows that the patch needed to configure autorun/autoplay has been in place for quite a while now. I cannot remember when it became available and I started trying to make it work. Prior to this discussion, I don't recall reading anything about "redirecting legacy .INI files" such as Autorun.inf to NULL. According to Windows Explorer Search, there is no autorun.ini file on the HDD and only one autorun.inf file, in C:\Windows\system32 -- for the HP Deskjet printer. The value autorun.ini is found in the Registry key: HKEY_CURRENT_USER\Software\Microsoft\Search Assistant\ACMru\5603 and the same values as it has are in the key: HKEY_USERS\S-1-5-21-682003330-329068152-725345543-1004\Software\Microsoft\Search Assistant\ACMru\5603 Currently, the Explorer Policies key NoDriveTypeAutoRun = FF. I might try DF instead. However, in my experience thus far, Autorun endlessly loops when I insert a DVD or CD disc on which there is no autorun.inf file. Most discs that I burn contain only archived data and/or perhaps some installers for outdated software that might be needed to access the archived data. It would be convenient for installing some software from the original CD-ROM if I could use autorun for the DVD and CD drives, which are installed in the hardware case, thus aren't readily "removable". Thanks for mentioning NoDriveAutoRun and Tweak UI. I've used Tweak UI and dimly recall it has something about limiting autorun to specific drives, but I'm not sure whether I have ever used it. The DVD and CD drives have always been drives D and E. The external USB Maxtor HDD is Drive F. So I will take another look at Tweak UI, and see whether using NoDriveAutoRun with NoDriveTypeAutoRun = DF will work without causing Autoplay to enter an endless loop. Quote: [i]"As to optical disk autorun risks; this is huge, when the dumbo MS disk-writing system keeps a buffer of "files to be written to disk", which can be seeded with malware."[/i] Ah, I've always suspected that there is some way that malware could insinuate itself onto an optical disc. Thank-you for mentioning it. If the malware files have read-only, hidden and/or system attributes, then I would see them with Windows Explorer regardless. (Not that I've ever found an autorun.inf file which has those attributes, either.) However, I always burn discs with NTI CD-Maker, a commercial utility, and not the native Windows XP function. It, too, has a buffer into which it loads content pending write, whether malware can identify the buffer and exploit it -- or maybe a malware program could have some other method to force the utility to include its own files. I've been looking for an alternative to the NTI utility, but the ones that I find either (1) don't have enough versatility and features or (2) they are monster programs like Nero, which is way more than I need to use or want to pay. FWIW, in my experience, file associations are specified in Registry keys that usually pertain to the program to which the filename extension is assigned and vice-versa. For example, the .HTML association is in Registry keys HKEY_USERS\S-1-5-21-682003330-329068152-725345543-1004\Software\Classes\.html HKEY_USERS\S-1-5-21-682003330-329068152-725345543-1004\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html Hmmm.... in my experience with uninstalling Google Chrome, there are others, but the Edit > Search doesn't return those keys.

cquirke
cquirke

Let's forget Grope Policy, because XP Home isn't designed to be a network chew-toy :-) That leaves 2 ways to kill \Autorun.inf processing. The most effective (which I'd have to look up again) is use a facility to redirect "legacy .ini files". If you define "Autorun.inf" as such a file and direct it to nothing, it's no longer processed - so you still have your Autoplay. The downside is, you lose Autorun.inf for optical drives, which some may like to preserve. Next, you can use NoDriveTypeAutoRun = FF to kill ALL devices (don't use 91 or 95, they are weak settings; use FF for None and DF to allow only optical drives). But there are two issues; unpatched, XP fails to honor the setting, and as it is a per-user setting, you have to apply to ALL accounts in HKU. Finally, you can suppress by drive letter rather than device type, using NoDriveAutoRun. This is also per-user, and as it's fiddly to work out the values, I use TweakUI to apply this in XP. This works where the (optical) drive you want to preserve has a consistent drive letter; no good for removable optical drives, as is typical for small notebooks. Where I have to preserve \Autorun.inf for optical drives, I can't use the legacy .ini trick, so I use a cross-fire of NoDriveTypeAutoRun = DF and NoDriveAutoRun to suppress all but the optical drive's letter. This way there's no risk from U3 flash drives that spoof their type as "optical" because they won't have the allowed drive letter. The OS has "the patch" of course. As to optical disk autorun risks; this is huge, when the dumbo MS disk-writing system keeps a buffer of "files to be written to disk", which can be seeded with malware. So if you are capable of opening Autorun.inf in Notepad (the default file association for .inf), and reading it to find the .exe to run, you're better off killing all \Autoruin.inf, optical disks included. It should definitely be suppressed for hard drives and net shares, which 91 and 95 don't do.

Ocie3
Ocie3

whether autorun/autoplay would create a security vulnerability. Malware introduced from a CD or DVD disc is probably rather uncommon. In contrast, malware introduced from a USB storage device is a very significant risk. The Microsoft techs were just thinking that it would be much more convenient to use the "CD player" to launch games or play music, install software, etc. if the action began when the user simply inserted the CD and closed the tray (ditto for DVDs). Of course, it was meant to be used to install software, whether it [i]would[/i] be perverted to install malware would be difficult to ascertain at the time. It is worth remembering that the risks 8 years ago are not what they are today. USB 1.0 preceded Windows XP by at least a couple of years, but the original Windows XP USB drivers were for I/O peripherals (mouse, keyboard, printers) and did not envision storage devices. USB 2.0 became standard (at least with regard to implementation) about a year after Windows XP was released, which is when I bought this computer. FWIW, the USB 2.0 drivers on my computer are from NVidia (the mainboard has the nVidia nForce2 chipset) and they do support storage devices. IIRC, that was also implemented in Windows XP Service Pack 2, or maybe earlier in SP 1A. Before USB, I knew many people who had serial-port HDDs, and not only SCSI, but "ZIP drives" which had capacities of about 250 MB (yes, MB) which was respectable at the time.

Neon Samurai
Neon Samurai

.. there's your problem right there. Thank Microsoft for your insecure by design version.

Ocie3
Ocie3

with Windows XP Home Edition. There is no Group Policy snap-in available. The Local Users and Groups snap-in appears on the list but when I select it, to Add it, a message declares that I cannot use it on Windows XP Home Edition. I must use the Control Panel User Accounts feature instead. So far though, using the value "FF" for the Registry key apparently works, and Windows XP has not replaced it with the default.

Neon Samurai
Neon Samurai

(If you don't already have the group policy editor in an MMC window) Start -> Run = "mmc" File -> add/remove snapin - [Add] -> Group Policy Editor - Group Policy Object = "Local Computer" - [Finish] (now that you the group policy editor) Local Computer Policy -> User Configuration -> Administrative Templates -> System - Turn off Autoplay = Enabled - Turn off Autoplay on = "All Devices" Local Computer Policy -> Computer Configuration -> Administrative Tempaltes -> System - Turn off Autoplay = Enabled - Turn off Autoplay on = "All Devices" Enjoy your Windows now behaving properly with removable media. Now, why those same settings placed in an AD policy don't properly effect subordinate workstations; I don't know. We had to make the change on the local machines before it would take effect. Maybe the newest MS-LDAP version works properly and maybe Vista/Win7 recognize it. But for WinXP, do it quick/easy/peasy through the machine's own Group Policy snap-in.

Michael Kassner
Michael Kassner

I missed that in my research. Glad I have experts to help me.

Editor's Picks