Brazil is the biggest country in Latin America with a population of over 198.7m people, 34% of whom are connected to the internet. It is also a country with a low GDP per capita ratio and higher rates of criminality, especially relating to cyber crime. With tens of millions of users already using online banking services in Brazil, cyber criminals find Internet banking an attractive target, particularly in the application of banking Trojans used to bypass two-factor authentication systems and other security countermeasures.

MessageLabs Intelligence has seen many Banker Trojan attacks in the past, however, more recently, I came across two different banks that were being targeted by one single attacker: Bradesco and Sicredi. MessageLabs Intelligence had been blocking the Bradesco banking attack some days ago, but then I noticed the Sicredi Bank attack on Saturday 20 February. It was early in the morning and none of the well-known anti-virus companies were detecting this malware, except for Symantec. See the full Virus Total report here: [Virus Total Report]

The malware had been zipped and attached in emails sent to a number of Symantec Hosted Services clients. Both forms of the attack used attached different files and had different subjects and sender information, in each case using spoofed email sender addresses that pretended to be official bank contacts, as can be seen in one of the examples following:

[Banking Trojan attached to email – first sample]

Compare this with the following example, of an attack against the other Brazilian bank, and it can be seen that the same body text was used in both cases, substituting the name of the bank where appropriate:

[Banking Trojan attached to email – second sample]

The attached executable samples were compiled using Visual Basic and the Inno Setup installer, and if opened, the installation procedure displayed the appropriate banking logos and branding, as can be seen in the examples below, intended to deceive the recipient into installing this application:

[Banking Trojan Installation – first sample - part one]

[Banking Trojan attached to email – first sample - part two]

Once complete, the installation process creates entries in the All Programs folder and creates a desktop icon. The icon also resembles the actual Bradesco or Sicredi Bank logo.

[Banking Trojan link added in All Programs]

Once the user click on the application, it opens a window, which appears exactly as expected, using the same design as online banking interface website; however, behind the scenes, the banking Trojan is covertly collecting the users login credentials and passing them back to the cyber criminals, as seen in the network traces below:

[logging of application network traffic – first example]

[logging of application network traffic – second example]

During the course of my investigations, I entered some false information to see how the Trojan would respond, and as I expected, the process simply continued to the next step, and asked for the user’s login security keys:

[Banking Trojan requesting user’s security credentials]

The Trojan also asked to verify that the correct keys had been entered before handing over the account information to the criminals’ servers.

At the time of writing, MessageLabs Intelligence has identified more than 300 different instances of these attacks, which were being sent to a variety of financial and non-financial organizations, and Symantec Hosted Services continues to protect its clients against these attacks.

News of another plane crash shook Americans on Thursday morning. Reportedly, a begrudged pilot, furious with the Internal Revenue Service (IRS), intentionally crashed a small plane on the building that housed the agency’s office in Austin, Texas. Although the said incident was tagged “an isolated event” and not an act of terrorism, cybercriminals launched their own “terrorist” attack by scaring unknowing users using another FAKEAV variant to gain profit.

Using the usual blackhat search engine optimization (SEO) techniques FAKEAV peddlers use, this variant immediately tops search results when users try to find news updates about the said incident. Clicking the malicious link leads to the download of TROJ_FAKEAV.LGJ.

Apart from being scammed into buying a useless application, users who are tricked into clicking the malicious link and filling up the order form can also fall prey to data or, worse, identity theft should the perpetrators decide to sell their credentials (i.e., credit card numbers and other pertinent personal information) to the highest bidders in underground markets.

Trend Micro™ Smart Protection Network™ protects product customers from this and similar threats by blocking user access to all related malicious sites via the Web reputation service and by detecting and preventing the download of malicious files like packupdate_build6_195.exe, aka TROJ_FAKEAV.LGJ, via the file reputation service.

Non-Trend Micro product users, on the other hand, can also stay protected from such threats via free tools like Web Protection Add-On, which has been designed to block access attempts to potentially malicious websites in real-time.

In a pump-and-dump attack, spammers raise the stock prices of companies they own shares in by sending spammed messages with misleading or outright untrue positive news about the said companies. Once the companies’ real stock prices have sufficiently risen, the spammers will then sell or dump their own shares to gain profit.

TrendLabs engineers, however, recently saw the recent comeback of this tactic hit the popular VoIP application, Skype. Spammers used the application’s instant-messaging (IM) feature to send the pump-and-dump spammed messages below.

Spammers tried to promote two companies—EcoBlu Products, Inc. and Terra Energy & Resource. Like other spam runs using IM applications, Skype users received these email messages from users who were not in their lists of contacts.

As usual, we urge users not to click any link in messages sent via email or IM applications that come from people they do not know.

Trend Micro™ Smart Protection Network™ protects product users from this threat by preventing the spammed messages from reaching their inboxes via the email reputation service and by blocking access to malicious sites via the Web reputation service.

Non-Trend Micro product users, on the other hand, can also keep their systems safe by using free tools like eMail ID, a browser plug-in that helps identify legitimate email messages in your inboxes.

In an attempt to affect as many users as possible, cybercriminals poisoned Google search results regarding the upcoming event. As usual, clicking the malicious links to get the latest news lead to sites that either host a bogus Windows Media Player update (see Figure 1) or FAKEAV.

Trend Micro threat analyst, Norman Ingal, found that sites that led to a bogus Windows Media Player update, which urged users to download player_update.exe-1, actually asked them to download a malicious .EXE file detected by Trend Micro as BKDR_INJECT.ANI (see Figure 2).

BKDR_INJECT.ANI drops an encrypted system file (config\qkqitqie.sav) onto affected systems then connects to the site http://{BLOCKED}ock.info/install/setup.php? to possibly download more malware.

The sites that lead to at least three FAKEAV variants (see Figure 3), on the other hand, download TROJ_FAKEVIME.AB, a FAKEAV component that connects to any of these two sites to download TROJ_FAKEAL.SMDP (aka Security Antivirus):

We recently upgraded our scanner on Virus Total to include our new reputation-based security engine. That has caused a spike in our detection rates, in particular Suspicious.Insight detections, and so I thought I’d take a few minutes to explain some of the background and what is going on.

So what exactly is a Suspicious.Insight detection? These detections are derived from Symantec’s new reputation-based security technology. They highlight files that have not yet developed a strong reputation (either good or bad) amongst Symantec’s community of users. Our goal is to keep our users’ machines safe, and part of achieving that goal means helping our users make informed choices about the files they allow on to their systems. Suspicious.Insight detections help shine a spotlight on files that have not yet developed a full reputation.

Why are we doing this, and what’s wrong with the conventional approach to security using traditional antivirus signatures? Unfortunately, traditional antivirus techniques are no longer as strong a defense as they used to be. Over the last few years Symantec has observed a seismic shift in the threat landscape. Consider this: ten years ago, Symantec published little more than a few handfuls of new virus definitions each week. Today that number has grown dramatically and we currently publish, on average, well in excess of fifteen thousand new virus definitions each day. So, why is this? Well, virus writers have realized that that once a virus definition for their malware exists, their game is over. So instead of hoping that a new threat will make its way across the globe to a large number of people and not be blocked by an security product’s latest signature, they are today focusing their efforts on shape-shifting as frequently as possible to avoid the traditional detection methods. They use techniques such as server side polymorphism, obfuscation, and encryption to cloak their threats in a disguise, and then change that disguise as frequently as possible. So today, the vast majority of malware is generated in real-time on a per-victim basis, which means that each such malicious program will be rated as being entirely new and low-prevalence by a reputation-based system. In contrast, most legitimate software has vastly different characteristics—it often comes from known publishers, has high adoption rates, shares much in common with earlier versions of the software, and so on. The Suspicious.Insight detection, therefore, is meant to inform the user that a given application is unproven and not yet well known to Symantec’s tens of millions of users.

Does this mean that all Suspicious.Insight detections will be flagged by Norton and Symantec products? No, and for several reasons:

• This detection looks at many different aspects of a file, including how it arrived on the system, publisher information, when it arrived, etc. Using these attributes, most users do not see Suspicious.Insight detections on clean files. (Note that on an online scanner such as VirusTotal, many of these attributes are absent, hence a Suspicious.Insight detection will be more likely). In effect this means that most users will never encounter a Suspicious.Insight false positive.

• Today, Norton products warn the user about Suspicious.Insight detections, they do not block these files. The file is labeled "unproven," and the user is allowed to make the final decision. Note that future versions of Symantec's corporate Endpoint Protection products will include reputation and will allow administrators to configure blocking policies based on their specific tolerance for risk.

• Due to the nature of our reputation system, even if a clean file is initially flagged as "unproven" (which is rare), it will typically develop a good reputation very quickly—usually within a day or two.

Ultimately the goal of Suspicious.Insight is to empower our users to make better informed choices about the software they allow onto their machines.

Since the beginning of the year, Adobe and Microsoft have been under a bad light since most of the most recent attacks notably exploited the two companies’ software vulnerabilities.Adobe Reader and Acrobat, in particular, are currently cybercriminals’ favorite targets. When news that Adobe would be releasing an out-of-band security update to prevent an exploitable hole in certain versions of Adobe Reader and Acrobat, some raised their brows in question while some rolled their eyes and declared that this was the last straw.

According to Adobe’s latest security bulletin, the said critical vulnerability could affect Adobe Reader 9.3 for Macintosh, Windows, and Unix; Adobe Acrobat 9.3 for Macintosh and Windows; and Adobe Reader and Acrobat 8.2 for Macintosh and Windows based on reports from Microsoft and Michael Yong Park. If cybercriminals exploited the said vulnerability, they could make unauthorized cross-domain requests or worse take control of affected systems, similar to the effects of a flaw in Adobe Flash and Adobe AIR Park also spotted days earlier.

According to ZDNet, Adobe insisted that there were no active expoits in the wild targeting the said vulnerability. TrendLabs engineers, on the other hand, have documented a number of noteworthy incidents wherein cybercriminals utilized Adobe Acrobat and Reader vulnerabilities, specifically in the way these software handled JavaScript:

"Sadly, this botnet documented by NetWitness is neither unusual nor new. For the past several years at any given time, the number of distinct ZeuS botnets has hovered in the hundreds. At the moment, there nearly 700 command-and-control centers online for ZeuS botnets all over the world, according to ZeuStracker, a Web site that keeps tabs on the global threat from ZeuS."

It seems that a recent Windows “patch” has been the cause of a series of blue screen crashes after users install a so-called Microsoft security update. The said patch, MS10-015, is said to be linked to this system malfunction, which leaves user systems with blue-screen-of-death (BSoD) errors.

According to an entry in the official Microsoft Blog, the distribution of the said Windows Update has since been suspended. However the company also issued a statement that the cause of the BSoD error may be malware related.

Trend Micro engineers found that TROJ_TDSS.AJD patches atapi.sys, which turns the .SYS file into a rootkit detected as TROJ_TDSS.SME. This then causes updated systems to crash, right after installing the security update.

“Kneber” = Zeus

Recently, Symantec observed some high-profile coverage of a threat being reported as a new type of computer virus known as “Kneber.” In reality Kneber is simply a pseudonym for the Zeus Trojan/botnet. The name Kneber refers to a particular group, or herd, of zombie computers (a.k.a. bots) being controlled by one owner. The actual Trojan itself is the same Trojan.Zbot that also goes by the name Zeus, which has been observed, analyzed, and protected against for some time now.

Since Zeus/Zbot toolkits are widely available on the underground economy, it is not uncommon for attackers to create new strains, such as Kneber, of the overall Zeus botnet. Though it is true that this Kneber strain of the overall Zeus botnet is fairly large, it does not involve any new malicious threats. Thus, Symantec customers with up-to-date security software should already be protected from this threat. Symantec detects the Zeus Trojan, otherwise known as Trojan.Zbot, as the following: • Trojan.Zbot • Trojan.Zbot!gen • Trojan.Zbot!gen1 • Trojan.Zbot!gen2 • Trojan.Zbot!gen3 • Trojan.Zbot!gen4 • Trojan.Zbot!gen5 • HTTP Trojan Zbot Domain (IPS) • HTTP Zbot Malicious File Download (IPS)

Check out the blog post Zeus, King of the Underground Crimeware Toolkits on Symantec’s Security Response blog to get a better feel for how an attacker can use the Zeus toolkit to create their very own string of the overall botnet. Also, Symantec has an extensive analysis of the Zeus botnet in the previously published whitepaper entitled Zeus: King of the Bots.

Symantec has also observed cybercriminals seeking to exploit computer users’ fears—spurred by all of the coverage that this threat is receiving—by poisoning search engine results for keywords such as “Kneber Botnet Removal.” In fact, when analyzed by Symantec, the highest ranked result on Google using these search terms led to a site hosting rogue antivirus software. Here’s a screenshot of the scareware in action:

The word spread that the Tidserv gang have patched their rootkit to avoid the infinite reboot issue due to API offsets changes in the kernel module introduced by MS10-015, so we ran our own tests on the following samples, which are said to cope with such kernel updates: MD5: 0370db3da46a580c600e99efd6d44d1b MD5: e1212a8cf64d5157d02bf2175c16ab25

These samples use the following two configuration files (config.ini extracted from Tidserv's Encrypting File System) and are the latest Tidserv samples we have in our lab:

One can observe the time difference between the build dates of these two versions is about 16 hours, which is quite small compared to other threats.

Another thing worth mentioning is that the installer/dropper's debug message has been changed to:
"We should have shotguns for this kind of deal."

After successful installation the infected drivers were indeed able to cope with changes in the kernel API offsets. In order to achieve that they now use hash functions on required API names to retrieve their addresses on the fly:

This technique is known to have been used in viruses and other threats for years, and yet they had to disable most of their bot network in order to use it, as Symantec's IPS monitoring system shows:

Note the drop in infection pings once the MS10-015 was released on 02/09/2010.

Here's how the infection distribution by top 15 countries looks like:

However, with both samples that was just a fortunate case where the driver was correctly infected; the majority of the time the computer was found to infinitely loop into the infamous BSoD at restart, and that's without applying MS10-015:

Yes, that's a digital picture: we had to use a real machine to try the latest variants, since they were a bit 'shy' inside virtual machines. In other words, they wouldn't install properly in VMs.

After some post-mortem analysis, it turns out that the EntryPoint and Checksum fields in the PE header structure of the infected drivers have been changed, while the viral code injection did not complete, thus leaving the entry point of the driver with invalid code:

The code shown above represents the original data bytes from the driver's resource section, which the CPU did not like so much.

Properly infected driver entry point should look like this:

Statistically it has been shown that the number of bugs in a program is proportional to its complexity, or it's source code size. Also, in kernel mode, the smallest mistake leads, in most cases, to a BSoD. Add to that a bit of laziness, rush and lack of QA and you can guess what's going to happen. On the other hand this may mark the beginning of the end of an otherwise advanced rootkit. Sadly, the end users who got infected are the ones who've paid the price.

Thanks to Vikram Thakur for his assistance in generating the infection statistics.

Would somebody please tell us why there's so much hype regarding privacy issues and Google Buzz?

Buzz integrates into Gmail… an e-mail service that reads (i.e. analyzes) your messages in order to target you with more specific ads, right? We recall objections being made about this analysis when Gmail launched. Has everyone forgotten this? Isn't this just the same tune being played once again?

Is anyone really that surprised that Google so aggressively rolled out automatic sharing features to Buzz?

It seems to us like a win-win situation. Either Google launches Buzz, to minimal objections, or else, they receive a great deal of free publicity while they "fix" the reported privacy issues. Google's launch of Buzz certainly created notable buzz in the press.

That's ultimately important for the search giant because unless they encourage sharing from their own services, they'll be losing out on future revenues to providers such as Facebook.

In fact, Facebook is already the world's largest news reader according to hitwise. It should not go without mention that Facebook's recent homepage update moved their search field towards the center of the screen. It's all connected.

Sharing is tomorrow's search and the players are beginning to battle it out. Your privacy is at stake, if you let it be. It's a trade off folks. You don't get to use free services and expect to get absolute privacy. Either you offer up some of your information for enhanced services, or you don't.

Remember, Google isn't your friend. It's a business.

If you really need privacy, use something else besides Gmail (and other free web based solutions). Some folks actually pay for their e-mail services, you can get something more secure for something like $20 a year, and that's cheap when you think about it.

We wanted to provide you with an update on our ongoing investigation into the “blue screen” issues affecting a limited number of customers who installed MS10-015.We have been working around the clock with our customers, partners and several teams at Microsoft to determine the cause of these issues.Our investigation has concluded that the reboot occurs because the system is infected with malware, specifically the Alureon rootkit.We were able to reach this conclusion after the comprehensive analysis of memory dumps obtained from multiple customer machines and extensive testing against third party applications and software.The restarts are the result of modifications the Alureon rootkit makes to Windows Kernel binaries, which places these systems in an unstable state.In every investigated incident, we have not found quality issues with security update MS10-015.Our guidance remains the same: customers should continue to deploy this month’s security updates and make sure their systems are up-to-date with the latest anti-virus software.

Customers continue to emphasize the importance of quality updates, and that high quality updates encourages quicker deployment.While the issue customers are experiencing with MS10-015 was caused by a malware infection and not a problem with the security update, we wanted to use this event as an opportunity to explain why this issue was not caught during testing, and how we respond to reported issues in our security updates.

This issue was not caught as part of our testing because oftentimes when malware is present, infected systems are put in an unstable state.These types of infections often leave the machine in such an unstable state that it cannot be reliably tested.This is because Malware writers use unsupported and potentially destabilizing methods for compromising machines because they want to keep their malware hidden from anti-malware software. In the particular case of Alureon, malware writers modified Windows behavior by attempting to access a specific memory location, instead of letting the operating system determine the address which usually happens when an executable is loaded.The chain of events in this case was a machine became infected, during which the malware made assumptions as to the layout of the Windows code on the machine.Subsequently MS10-015 was downloaded and installed, during which the location of Windows code changed.On the next reboot the malware code crashed attempting to call a specific address in Windows code which was no longer the intended OS function.

Microsoft has taken steps to deter tampering with the Windows Kernel using technologies like Kernel Patch Protection (sometimes referred to as PatchGuard) and Kernel Mode Code Signing (KMCS), both of which are enabled in 64-bit systems.These technologies make it possible to detect when integrity checks fail. The different versions of Alureon that we have investigated only infect 32-bit systems and would fail to infect 64-bit systems. That said, it is important to note that running as a standard user instead of using an administrator account is a best practice that in most cases will prevent kernel mode malware from infecting a system. Similarly, keeping anti-virus signatures current will also prevent most malware from infections. Additionally, since we have determined that 64-bit systems are not affected, we are opening Automatic Updates for these platforms.

Customers who are interested in additional technical details of what the Windows Kernel is can learn more here.

Even after security updates are released, the Microsoft Security Response Center’s job is not done.In conjunction with Microsoft Customer Service and Support (CSS), we monitor forums and track customer calls to ensure we respond to reported issues as quickly as possible.On Wednesday, February 10th, we became aware of reports regarding Windows XP SP2 and SP3 systems becoming unable to restart successfully after the installation of MS10-015. The reports were first identified by the MSRC’s monitoring of various online community support forums, a spike in support call volume and telemetry from our Consumer Security Support Center.After reviewing the information we had available, we stopped offering Automatic Update distribution of MS10-015 in order to minimize the potential for widespread customer impact while we investigated these reports.Even though we have stopped distribution through Automatic Update, we have seen a large number of deployments as customers can still deploy the update through Windows Update, WSUS or SMS.

In this situation, our teams needed to get information directly from the affected systems in order to understand the cause.Because we had so few reports and needed to examine the state of the affected systems, the CSS team even drove to customer locations to retrieve machines for analysis.

This past weekend, we worked with the Microsoft Malware Protection Center (MMPC) on the systems that were delivered to Redmond last Friday, and confirmed that all of the affected systems had the Alureon Rootkit installed. The Windows Engineering team then began working to build a test matrix to determine if the malware was related to the reports we have been receiving.To ensure we had identified the root cause of the issue, Windows Engineering tested machines using the test process covering all 32 bit versions of Windows.While this issue could impact any 32bit Windows system that was infected with the malware, since reports are predominately on 32bit versions of Windows XP this test process is described at a high level focusing on that version in the below table:

Phase

Actions

Result on Test Machines

Debug Phase 1

Install Supported Versions of Windows XP

Install all previous updates to bring the Windows Kernel prior to the version updated by MS10-015 to version 5.1.2600.5857.

Install the Alureon Root Kit.

Install MS10-015 / KB977165 Kernel Version 5.1.2600.5913

The system enters a repeated reboot / blue screen

Debug Phase 2

Install Supported Versions of Windows XP

Install all previous updates to bring the Windows Kernel to version 5.1.2600.5857

Install all previous updates to bring the Windows Kernel to Current Version prior to the version updated by MS10-015.

Install the Alureon Root Kit.

Successful boot

Debug Phase 3

Install Windows XP SP3

Install all previous updates to bring the Windows Kernel to version 5.1.2600.5857

Installthe MS10-015 security update the Kernel version to version 5.1.2600.5913

Install the Alureon Root Kit.

Successful boot

Debug Phase 4

Install Supported Versions of Windows XP

Install all previous updates to bring the Windows Kernel to version 5.1.2600.5857

Install MS10-015 to bring the Windows Kernel to version 5.1.2600.5913

Install the Alureon Root Kit.

Uninstall KB977165 setting the Kernel to version 5.1.2600.5857

The machine goes into a rolling reboot

As indicated in the table, the presence of Alureon does not allow for a successful boot of the compromised system. The Windows Engineering team continued testing different configurations, as well as retesting several third party applications, leading to our firm conclusion that the blue screen issue is the result of the Alureon rootkit.

A malware compromise of this type is serious, and if customers cannot confirm removal of the Alureon rootkit using their chosen anti-virus/anti-malware software, the most secure recommendation is for the owner of the system to back up important files and completely restore the system from a cleanly formatted disk.

While we cannot predict how malware writers will author or modify their code, we are committed to finding new ways to detect issues like this on infected systems. We’re also working on a simpler solution to detect and remove Alureon from affected systems which should be released in a few weeks, as are several other third party vendors.

We will keep you updated here on the MSRC Blog as we have more data and information on the malware and automatic remediation tools.

Restart issues on an Alureon infected machine after MS10-015 is applied

The Win32/Alureon family of malware is a complex set of components which perform various functions. These include the modification of DNS settings, search hijacking, and click fraud. Alureon has existed for several years and has undergone a number of evolutionary changes. The ability to “infect” the miniport driver associated with the hard disk of the operating system is a recent notable change. This functionality first appeared around August 2009. For the most common system configuration (for machines using ATA hard disk drives) , the ATA miniport driver ‘atapi.sys’ is the file which is targeted.

While the concept of modifying Windows system files as part of an installation method is not new, it is not a common approach. The file modification performed by Alureon overwrites the data in the target driver’s resource section with its own code. The entry point of the driver is modified to point to this code. By doing so, the malicious code is executed when the driver is loaded by the operating system. (Note that this infection method is mitigated on the 64-bit versions of Windows from XP SP1 onwards because of a technology called Kernel Patch Protection (“PatchGuard”)).

In order to invoke a given Windows API, the virtual address (VA) must first be determined. This determination is generally taken care of by the operating system when an executable is loaded. The information required to perform this operation is stored within the PE file itself.

However, malware (and other software) often employ other methods to achieve this. In this case, rather than manipulate the structures required by the operating system, Alureon resolves the addresses it requires “manually”. These are then stored as relative virtual addresses (RVA) within the body of the modified driver.

The figure below illustrates the code responsible for saving the RVA of the API “ExAllocatePool” at an offset relative +0x14 to the start of the resource section:

The figure below is the start of the resource section of an infected driver. The stored RVA is 0x38d66:

Inspecting the VA, which is calculated by adding the RVA to the image base of the kernel, we observe the start of the API, “ExAllocatePool”:

As part of the February security updates, an update (MS10-015) resolving a vulnerability in Windows Kernel was released. This update included a new operating system kernel. Inspecting the updated kernel at the same VA, we observe that this address no longer corresponds to the start of the “ExAllocatePool” API.

In the updated kernel, the VA of “ExAllocatePool” has changed. Therefore, after applying MS10-015, Alureon will now be attempting to make an invalid call. The result of this attempted call is a blue screen or potential startup hang on 32-bit Windows systems but reports have predominately been on Windows XP.

The author(s) of Alureon have since updated the driver infection routine. The latest version of Alureon (detected as Trojan:WinNT/Alureon.G) no longer relies on the use of hard-coded RVAs.

Restart issues can be resolved by replacing an infected driver with the original. This can be performed from the recovery console.

Last week we received quite a number of reports that the patch for MS10-015 was causing XP machines to display the dreaded BSOD (http://isc.sans.org/diary.html?storyid=8209). The comments of that diary already suggested that the BSOD may have been related to a rootkit on the machine and it looks like this was correct. If you were infected with the TDL3/TDSS/tidserv AKA Alureon rootkit and applied the patch, then you would get the BSOD as the patch changed some pointers and the malware now tried to execute an invalid instruction.

Lucky for us the malware writers have addressed this issue and it shouldn't happen again for those who are newly infected with this particular piece of malware. A shame really, as it was a convenient way in which to identify infected machines. If you did get the BSOD on your machine or on machines in your organisation, then you should consider the possibility that the machines are infected.

Marco's page (http://www.prevx.com/blog/143/BSOD-after-MS-TDL-authors-apologize.html ) and the Microsoft page (http://blogs.technet.com/mmpc/archive/2010/02/17/restart-issues-on-an-alureon-infected-machine-after-ms10-015-is-applied.aspx) go into the details.