Forgot your password?
typodupeerror
Security Windows IT

Rootkit May Be Behind Windows Blue Screen 323

Posted by kdawson
from the pre-owned dept.
L3sPau1 writes "A rootkit infection may be the cause of a Windows Blue Screen of Death issue experienced by Windows XP users who applied the latest round of Microsoft patches. It appears that the affected Windows PCs had the rootkit infection prior to deploying the Microsoft patches. Researcher Patrick W. Barnes, investigating the issue, has isolated the infection to the Windows atapi.sys file, a driver used by Windows to connect hard drives and other components. Barnes identified the infection as the Tdss-rootkit, which surfaced last November and has been spreading quickly, creating zombie machines for botnet activity."
This discussion has been archived. No new comments can be posted.

Rootkit May Be Behind Windows Blue Screen

Comments Filter:
  • by Anonymous Coward on Friday February 12, 2010 @01:33PM (#31115356)
    That's one way of forcing users to take care of an infection.
    • Re: (Score:2, Funny)

      by Anonymous Coward

      That's one way of forcing users to take care of an infection.

      Let me try to respin it into an anti-Microsoft jab:

      Windows API is such a jumbled mess of spaghetti code that not even low-level processes related to accessing the hard drive are safe from updates!

       

    • Re: (Score:3, Insightful)

      by Opportunist (166417)

      So I'd call that latest update a critical security fix. Install immediately!

    • Re: (Score:3, Funny)

      by SCPaPaJoe (767952)
      I sure am glad I have Vista!!!
      • Re: (Score:3, Funny)

        by FatdogHaiku (978357)

        I sure am glad I have Vista!!!

        I understand each of the words.
        I can pronounce all the syllables.
        Yet this string will not register in my brain...
        It's as if this arrangement of characters should not be.
        Like some great sacrilege has sprung into being.

  • After all, there's no way that their malware tool could have spotted it, or the update could have checksummed the files before patching them.

    If they put half as much effort into their anti-malware activities as they do into their DRM regime, the world would be a better place. We'd all have unicorns, and a pot of gold.

    • After all, there's no way that their malware tool could have spotted it

      If a system has been rooted, nothing short of booting to another OS from a known clean media, mounting the disk read only, and scanning, is guaranteed to detect a root kit.

      That'd make updates a real pain in the arse to install...

      • Re: (Score:3, Insightful)

        by PIBM (588930)

        Scanning it does not even guarantee the detection of the root kit. I can see tons of useless scans a user could run ;)

        • Re: (Score:3, Funny)

          by rarel (697734)
          I have a scanner, it's an Epson something. Doesn't do a damn thing, always gives me just a picture. These things are such a ripoff... :/
      • Re: (Score:3, Interesting)

        by Sockatume (732728)

        I'm not sure it'd be such a pain. Windows already demands to restart after critical updates anyway. Couldn't it throw a flag to boot from a secondary, encrypted, trusted "update partition" that only the Windows root can edit, and only during shutdown, then use that to mount the disk as read-only and install updates? You could call it Microsoft SafeUpdate, part of the Trusted Computing Initiative. Heck, make the secondary partition an SSD, give the hardware manufacturers a reason to get behind it.

        • Re: (Score:3, Interesting)

          by RoFLKOPTr (1294290)

          I'm not sure it'd be such a pain. Windows already demands to restart after critical updates anyway. Couldn't it throw a flag to boot from a secondary, encrypted, trusted "update partition" that only the Windows root can edit, and only during shutdown, then use that to mount the disk as read-only and install updates? You could call it Microsoft SafeUpdate, part of the Trusted Computing Initiative. Heck, make the secondary partition an SSD, give the hardware manufacturers a reason to get behind it.

          RootKit() {
          if ( RecoveryPartitionPresent() == 1 ) {
          WriteRandomShit(RecoveryPartition);
          }
          }

          • by Sir_Lewk (967686)

            What exactly would be the point of that? Infections senselessly trashing systems is pretty 1990. If the recovery partition is ever actually needed, that would mean the rootkit is effectively dead already, so why should it care what happens next?

        • by gbjbaanb (229885)

          You could call it Microsoft SafeUpdate

          or even Windows File Protection [slashdot.org] and only allow drivers that have been digitally signed [microsoft.com].

          Nice idea I suppose, but as they didn't work there's only one solution - DRM on everything in your C drive!!

        • by Tuidjy (321055) on Friday February 12, 2010 @02:19PM (#31116110)

          You know, it is far from easy to implement a "secondary, encrypted, trusted "update partition" that only the Windows root can edit, and only during shutdown" on a PC that has been rooted, unless you support this in hardware. And I can already hear the screaming and gnashing of teeth if some people, present company very much included, learned that PCs come with something like that.

          I would certainly not be happy running hardware that I knew had something that I and no one I know could get into. And I can get into it, it's not that "trusted", is it?

        • Couldn't it throw a flag to boot from a secondary, encrypted, trusted "update partition" that only the Windows root can edit, and only during shutdown, then use that to mount the disk as read-only and install updates?

          I'm pretty sure that if your system's been rooted, that's no protection at all. Besides, rootkits would quickly evolve to account for this process.

      • by Z34107 (925136)

        You're assuming your tool can detect the rootkit in any case.

        If it can detect it during an offline scan, it can probably detect it during an online scan too. (Of course, the rootkit will have the opportunity to hide itself or destroy your tool.) ComboFix and MalwareBytes are especially good at removing TDSS.

    • by girlintraining (1395911) on Friday February 12, 2010 @01:43PM (#31115518)

      After all, there's no way that their malware tool could have spotted it, or the update could have checksummed the files before patching them.

      Well, actually no. Most rootkits either modify the permissions or patch critical system files that cannot be easily replaced, as this one does. It's designed to be stealthy -- so if you scan it, it will return a byte-for-byte copy of the original, which is kept elsewhere, while the operating system loads the infected one at boot.

      Saying Microsoft is responsible for ensuring compatability with 3rd party software is ludicrious. This is like potholes -- while the government has a responsibility to patch the roads up so they remain drivable, cars are nonetheless designed with shocks and drivers are expected to watch for road hazards and avoid them as much as possible as well. It is a joint responsibility. Microsoft is not the sole responsible party here: The user shares the responsibility of ensuring the system has not been compromised.

      • by TheLink (130905) on Friday February 12, 2010 @02:16PM (#31116056) Journal
        > Saying Microsoft is responsible for ensuring compatability with 3rd party software is ludicrious.

        And saying Microsoft is responsible for ensuring compatibility with _malicious_ 3rd party software is even sillier.

        If your system is screwed up by a rootkit, there is no way to 100% predict what could happen if you try to continue using it (including trying to install patches).

        If the BSODs are only happening to rootkitted XP boxes then it's clearly not Microsoft's fault.
      • But when taken with Microsoft's entire approach, no.

        Microsoft has always chosen "ease of use" over security. And then their licenses are constructed so that a large segment of the machines out there don't even have clean-bootable media to resolve issues like this.

        In your pot hole analogy, Microsoft didn't build the road ... and then then pot holes appeared. Microsoft built the road with the holes ... and then even more appeared and they're doing nothing to mitigate the situation and they're still building t

    • by _xeno_ (155264) on Friday February 12, 2010 @01:44PM (#31115528) Homepage Journal

      Isn't one of the things a rootkit does is attempt to prevent detection?

      How do you know that they don't try and match checksums, only the rootkit was returning the "correct" data in order to hide its presence? I mean, it is in the system file that handles reading data from hard drives, which sounds like the perfect place to put in code designed to stealth out the rootkit.

      Not that I can get to the article ("Error establishing a database connection"), so I have no idea if that's the case, but it seems quite possible to me that if it's a rootkit, it's actively hiding from detection, which would seem to let Microsoft off the hook. Except for however the rootkit infected the machine in the first place.

    • by Loopy (41728)

      Clueless comment. Microsoft was NOT patching atapi.sys in this set of updates. Unless you're asking MSFT to checksum every single file that has one of their patch binaries as a dependency? (Think about that one for a second before your knee jerks.)

      • by PIBM (588930)

        The rootkit was hiding there, but there's nothing that prevent it from using other files which could have been modified (thus breaking hte rootkit compatibility ??)

      • How long would it take to checksum every executable and library on a windows machine, anyway? What makes this something that can't take place on a regular or manually initiated basis?

        • by Opportunist (166417) on Friday February 12, 2010 @03:04PM (#31116700)

          You can do it, but it's basically worthless if your system has been infected with a rootkit. The rootkit can (and usually does) show you a perfectly healthy system instead of the reality on the drive. As has been said before, the rootkit probably keeps a copy of the original file somewhere and only "shows" it to you in its original place (where now that rootkit file is located). It doesn't usually affect its operation, since it has already been loaded and unless it needs more data from its file (unlikely), nothing bad happens from the fact that the file that is loaded differs from the file that is shown on the disc.

          If you now try to calculate a MD5 from the file on the disc, you will be supplied the original copy (that was replaced by the rootkit) and calculate your MD5 from the healthy file, making it appear a_ok and fine.

          Once a system has been rooted you have lost. I hate to use the same words I always get to hear from consultants, but here they fit: You cannot identify some problems from within the system.

    • by Rockoon (1252108)
      You seem to be suggesting that atapi.sys was updated. Got any proof of that?

      You seem to be using the same failed logic as other people, that a file modification exists after it has been over-written. No, it actually doesn't. There are no ghostly modified bits that linger around. Clearly this file is doing something it shouldn't, which by definition means that it didnt get replaced in the update.

      If you arent a programmer or some shit, dont offer your opinion, because right now its terribly stupid.
    • by timeOday (582209)

      If they put half as much effort into their anti-malware activities as they do into their DRM regime, the world would be a better place.

      They're more or less the same thing - the spread of malware is unauthorized file copying. The only way to fully prevent malware is to stop users from installing software, since they sometimes install malware.

      The idea of not letting people install whatever they want on their own computers may sound ludicrous, but locked-down consoles have largely displaced PC's for gami

    • Windows File Protection is supposed to checksum and restore modified files. But if malware gets on your machine, all bets are off and it will likely be bypassed or tricked. In addition, it's a rootkit, so normal checksum scans are supposed to detect nothing, it's supposed to be good at hiding. Wouldn't be a very good rootkit if it was found by a feature not designed to find rootkits specifically.
    • by westlake (615356) on Friday February 12, 2010 @02:16PM (#31116050)

      After all, there's no way that their malware tool could have spotted it, or the update could have checksummed the files before patching them.

      If they put half as much effort into their anti-malware activities as they do into their DRM regime, the world would be a better place. We'd all have unicorns, and a pot of gold.

      Microsoft does detect it - and has since last October.

      File atapi.sys received on 2010.02.11 21:58:49 (UTC) [virustotal.com]

      Virus:Win32/Alureon.A [microsoft.com]
      Updated: Dec 07, 2009

      Aliases:

      Win32/Olmarik!generic (CA) Rootkit.Win32.TDSS.u (Kaspersky)
      W32/TDSS.drv.gen4.A (Norman)
      Mal/TDSSPack-V (Sophos)

      Encyclopedia entry

      Updated: Dec 07, 2009 | Published: Dec 02, 2009

      Aliases

      Win32/Olmarik!generic (CA) Rootkit.Win32.TDSS.u (Kaspersky)
      W32/TDSS.drv.gen4.A (Norman)
      Mal/TDSSPack-V (Sophos)

      Alert Level
      Severe

      Detection initially created:
      Definition: 1.69.77.0
      Released: Oct 23, 2009

      There are no common symptoms associated with this threat. Alert notifications from installed antivirus software may be the only symptom(s). When the infecting trojan is run, it infects a system driver, usually 'atapi.sys'. It has also been observed to infect 'iastor.sys' but other system drivers may also be targeted. The system driver detected as Virus:Win32/Alureon.A is infected by the addition of code, whose function is to load a part of the Alureon rootkit. The Alureon rootkit is a component that gives Alureon the ability to avoid detection; it is created by the same Alureon trojan that infects the system driver. The rootkit loaded by Virus:Win32/Alureon.A has the ability to avoid behavior blockers, which allows it to perform its malicious routines uninterrupted. It can also hide files and disk sectors.


      Manual removal is not recommended for this threat. To detect and remove this threat and other malicious software that may have been installed, run a full-system scan with an up-to-date antivirus product such as Microsoft Security Essentials... . Win32/Alureon may modify DNS settings on the host computer, thus the following steps may be required after the Win32/Alureon removal is complete:
      If the computer has a network interface that does not receive a configuration using DHCP, reset the DNS configuration if necessary

    • by psetzer (714543)

      This is pretty ironic considering the circumstances. Their DRM code is pretty much the standard process and kernel isolation plus hardware support for looking to see if anyone's messed around with critical system files to bypass that.

    • by cgenman (325138)

      On the one hand, I'd agree with the other posters that detecting rootkits once they're installed is incredibly difficult.

      On the other hand, that windows is so rootable is a problem. Yay for adding malware tools to window. But the standard operating procedure of adding layer after layer of new code for new functionality is getting pretty creaky. It opens more avenues for rootkits and other problems to break through.

    • by Opportunist (166417) on Friday February 12, 2010 @02:49PM (#31116522)

      As much as I hate defending MS, I can't help but doing it here.

      A rootkit (and that is one) in a system means that you, being software running on that system, have no chance of detecting it, at least if it has done its homework. For the patcher, those checksums might even have been correct.

      It also needn't be manipulated files. Windows, as any OS that has to allow low level drivers, allows you to load non-MS ring0 drivers. Like, say, Linux. It's either that or writing a device driver for every single pesky little controller out there. Do you think MS would do that? Or even do it well?

      Now, you don't need drivers for hard drives themselves, but for their controllers. And spyware is quite keen on snuggling up to those controller and "filtering" the calls between them and the OS. Now, those spyware drivers are deemed part of the I/O system (for obvious reasons, they are part of the HD controller drivers as far the OS is concerned). If that driver cannot be loaded because that patch fixes a loophole the spyware used, the OS identifies that as a critical error in the HD controller driver and cannot access the hard drive anymore. BSOD.

      The very same would probably happen in Linux, in BSD, in ... whatever Apple's OS is called, I forgot. You have a driver that is deemed critical by the system that fails to load.

      If you want to blame anything on MS here, it's probably that this rootkit drivers could be installed in the first place. And I honestly don't know if it's MS to blame or the user. What should MS do if the user clicks "allow" on anything he gets asked? Take away control from the user? I doubt you'd like that.

  • SFC Find It? (Score:3, Insightful)

    by ircmaxell (1117387) on Friday February 12, 2010 @01:34PM (#31115384) Homepage
    Will the windows SFC (System File Checker) tool find this altered file?
    • Re: (Score:3, Informative)

      by RayMarron (657336)

      Not if the rootkit responds to the request with the original values for the files it has replaced. That's the the thing about a rootkit - it gets to tell the OS whatever it wants.

      • Is that how SFC works? It calls a method in the DLL? I would think it would do an MD5 (or similar -- possibly stronger -- hash) on the file, and compare the hash and the size to the known values. The only way around that would be to alter what SFC has for the "original" values... But then wouldn't SFC launched from a bootable CD combat that issue?
        • Re: (Score:2, Informative)

          Generally, rootkits will modify function pointers in the kernel so that typical detection activities are trapped and handled so that the system appears unaltered. In the case of file access, the original file (in an alternate location, data stream, etc.) can be accessed in place of the trojaned one that was loaded on boot, thus preserving original the file size and contents.
        • Is that how SFC works? It calls a method in the DLL? I would think it would do an MD5 (or similar -- possibly stronger -- hash) on the file, and compare the hash and the size to the known values. The only way around that would be to alter what SFC has for the "original" values...

          The obvious other way around it would be to intercept file read/write calls (which trojan can do if it lives on kernel level, injected into some driver), and provide the original file contents to anyone who tries to read the file.

          But then wouldn't SFC launched from a bootable CD combat that issue?

          It would, but can you launch SFC from within one OS install on files belonging to another OS install?

        • by RayMarron (657336)

          My comment applied only to running it in-place. Booting from CD is, AFAIK, the only way to see/get rid of rootkits. (My apologies if that's the way SFC is normally run)

  • by Dan East (318230)

    The infected PC is unusable or it will be restored to a clean state. Either way it won't be spamming or participating DDOS attacks, etc.

  • No surprise if true (Score:5, Interesting)

    by al0ha (1262684) on Friday February 12, 2010 @01:42PM (#31115492) Journal
    I've performed a forensic analysis on numerous Windows machines and have discovered rootkits that have lived on machines undetected for up to two years even though they were up to date on patches and AntiVirus defs. In fact one of the rootkits was unknown until I discovered it and sent a copy to threatexpert and virustotal.
    • Can you give us a little more information on how you discovered these rootkits?
      • by berashith (222128)

        It was named al0ha.trojan.jpg.exe and it was also sent to thousands of unsuspecting hotmail users at the same time as it was sent to threatexpert and virustotal ( they only got it as a secondary action) .

      • by The MAZZTer (911996) <<megazzt> <at> <gmail.com>> on Friday February 12, 2010 @01:57PM (#31115750) Homepage

        If you compare a file listing run from inside the machine to one run from a bootable CD OS where the rootkit can't load, different files are a dead giveaway that something is being hidden, and a rootkit can't work around this.

        There are also lower level APIs one can use inside of an OS that are much harder for a rootkit to patch so such tools can also locate some rootkits without needing to boot from CD. See: RootkitRevealer

      • I had a machine with a rootkit on it (my parents laptop) file called srosa.sys - the only clue there was something wrong with the PC at all was it wouldn't run autocheck.exe and any file called chkdsk.exe was automatically deleted.

        It also prevented the installation of any virus scan package - literally deleting and modifying files as they were installed.

        Its like that hacker defender rootkit a lot of admins ran into a few years back (but didn't know about it) they were calling support about the information s

    • by lymond01 (314120)

      If you run your XP box as root and allow items to be installed by clicking on an attachment or going to a website that runs an executable, no virus checker is going to stop you from hosing your machine. Vista's "cancel or allow" mechanism made fame by its annoying implementation (having to "cancel or allow" multiple times through a single process) but it was the best move Microsoft ever made towards their system's security. MacOS X and Linux have had "cancel or allow" mechanisms pretty much since their in

  • ...my XP box didn't crash on reboot after applying these latest updates.

  • had one yesterday (Score:2, Informative)

    by Revek (133289)

    Scanned the drive in another machine and it detected atapi.sys as having a trojan. I restored it from /i386 and it came right up. I never thought it was connectd with the xp problems. Microsoft didn't do a evil thing who would have knew.

    • Scanned the drive in another machine and it detected atapi.sys as having a trojan. I restored it from /i386 and it came right up. I never thought it was connectd with the xp problems. Microsoft didn't do a evil thing who would have knew.

      You mean Microsoft didn't have evil intentions in this area of the patch. Bad idea to make a blanket statement based on one area of patch.

  • by Ralish (775196) <ralish AT gmail DOT com> on Friday February 12, 2010 @01:51PM (#31115644)

    Next time you might consider doing some backwards compatibility testing with popular rootkits, yes? Just a free tip Microsoft!

  • VirusTotal (Score:2, Informative)

    by z4ns4stu (1607909)
    Here's a link to the report from VirusTotal when you upload an infected atapi.sys.

    http://www.virustotal.com/analisis/85aa49f587f69f30560f02151af2900f3dc71d39d1357727ab41b11ef828a7ff-1265925529
  • Apply this patch to see if the machine is infected by some seemingly-unrelated rootkit.
  • by davidwr (791652) on Friday February 12, 2010 @02:08PM (#31115934) Homepage Journal

    "Yes, our security update crashed your computer. We hope you enjoyed our anti-rootkit feature."

  • by cyprezzz (110690) on Friday February 12, 2010 @02:11PM (#31115984)

    I've seen this Tdss-rootkit on many machines. Usually it infects a disk driver like atapi.sys or iastor.sys. Typically an infected machine will boot in normal mode, but NOT in safe mode (blue screens). If Windows will boot, running ComboFix has removed the rootkit for me every time. The author of ComboFix is a genius.

  • ATAPI.SYS Infections (Score:5, Informative)

    by nlewis (1168711) on Friday February 12, 2010 @02:24PM (#31116200)

    I run a small computer repair shop, and we first started seeing this ATAPI.SYS virus a few weeks ago. When I would submit it to VirusTotal, it would always come back as clean on every single virus scanning engine - but I could tell it was infected. I even had a computer in here just yesterday which had the infected ATAPI.SYS file, yet it was not detected as such - even when the hard drive was mounted as a secondary drive in another system and scanned with several up-to-date antivirus programs.

    The virus itself is actually quite a clever little beast. After infecting the file, it sets the file modification time back to the original date & time, which makes it hard to tell that it's been modified. Also, I've noticed that the byte counts between infected and non-infected versions of the file are almost always identical. But to do that, it appears to be injecting its code into the area normally used to store the file version information. The upshot is, if you check the file properties and there's no file version information (the Version tab under XP or the Details tab under Vista/Win7), there's a good chance the file is infected.

    I have not had any computers come in to the shop with the BSOD mentioned in the articles yet, but I'm expecting them at any time...

  • by thatskinnyguy (1129515) on Friday February 12, 2010 @02:26PM (#31116238)
    Rootkit? I don't see it. Maybe it's because this damn blue screen is blocking my view.
  • by pydev (1683904)

    Mommy, the root kit did it!

  • by trytoguess (875793) on Friday February 12, 2010 @02:56PM (#31116630)

    The comments here suggest ideally using a bootable CD to scan the drive, but what exactly should one use?

Testing can show the presense of bugs, but not their absence. -- Dijkstra

Working...