AZHTCIA

A new rogue has started making its appearance from compromised websites: Rogue:MSIL/Zeven. We received a sample (70be8ca73142922fd78acf2aafa9f141a977f15a) and a URL and began our investigation.

Let us say from the beginning that the guys behind this rogue like to copy big-time. They start by auto-detecting what browser the user is currently using, and then faking the malware warning page if the browser is Internet Explorer, Chrome, or Firefox.  This is meant to be a social engineering scheme in order to trick the user into downloading and installing the rogue, relying on the user’s trust of his day-to-day browser.

The similarity between the fake warning pages is so accurate that it can trick even highly trained eyes.

In the Firefox page, for example, you can see it’s not the real warning page because they misspelled ‘out’ and wrote ‘Get me our of here’.

But for all three browsers, a common indication that you are not looking at the actual browser warning is the offer of some sort of an “update” or “solution”. All the “updates” point to a copy of MSIL/Zeven that promises to provide “a new approach to windows detection”. Internet Explorer, Firefox, and Chrome do not offer such a solution when a website is blocked.

When installed, the product looks very genuine: it allows you to scan files, tells you when you’re behind on doing your updates, and enables you to tweak your security and privacy settings. These features are usually available in various legitimate antivirus solutions. However, the features don’t work; everything is there just to look nice, not to offer any kind of protection (just like in all other rogue antivirus programs).

Of course once it scans your computer it’s bound to claim it found something scary (malicious), as shown below:

As usual with rogue scanners, although it “found” malicious files, it claims it cannot delete them unless you update. That implies that you need to pay for the full version, which has the ability to download updates. However, these files are totally bogus; no such files exist in the user’s computer.

If you decide to buy the product, this rogue opens an HTML window enabled with ‘Safe Browsing Mode’ and high strength encryption to “help” and ”protect” you while completing your purchase. Of course these features are totally worthless and don’t actually do anything in the way of securing your credit card details.

The main page of the rogue antivirus program itself looks awfully close to the Microsoft Security Essentials webpage – more copying from the bad guys. The people behind it have even copied the awards received by Microsoft Security Essentials and link to the Microsoft Malware Protection Center -  pretty sneaky of them.

This is a screenshot of the rogue’s main webpage:

And, by way of contrast, this is a screenshot of the genuine Microsoft Security Essentials page:

It seems that these guys want to profit on the good reputation and success of Microsoft Security Essentials in order to make money - but we remind our customers that Microsoft Security Essentials can be downloaded at no cost. And it really does protect your computer from malware!

We detect both the downloader of the rogue and the rogue itself as Rogue:MSIL/Zeven.

Until our next encounter: browse safely!

Daniel Radu
MMPC Dublin

It's very important your computer, software and browser are running with the latest updates, but it's equally important to be discerning about where your updates are coming from.

A perfect example of the latest update scam: Recently, we observed malware writers using compromised Twitter accounts to post the fake tweets about the 'latest TweetDeck update' as mentioned on the TweetDeck Support portal. The tweet contains a URL that points to the fake TweetDeck update file called 'tweetdeck-08302010-update.exe', a small executable file 95KB in size. When the file is run, nothing appears to happen, but in the background, malware will infect the computer.      

Microsoft anti-malware solutions protect against this threat, detected as Trojan:Win32/Alureon.CT.

The lesson here: Don't respond to alarmist demands to update or else! Verify where your update is coming from; make sure you are getting updates from a reputable vendor.   

Happy tweeting!!!

- Hil Gradascevic & Jasmine Sesso

Back in May, we posted an article with an update on Win32/Alureon. As the numbers demonstrate, we have been making a positive impact in terms of protecting customers from this family of attacks. Since releasing the Alureon rootkit detection and removal capabilities in MSRT (the Microsoft Malicious Software Removal Tool), there have been over 1,200,000 successful removals of this family from machines.

In terms of detections by operating system, Windows XP continues to be the most common target, chalking up over three quarters of the detections across all platforms. Windows Vista and Windows 7 are relatively unchanged from the May report.

However, the authors of these attacks have not been resting. Just under a month ago, we became aware of a new variant of Alureon that infects the Master Boot Record (MBR) instead of an infected driver.  While this new variant did not affect 64-bit machines, it had an inert file called ldr64 as part of its virtual file system.  More recently, we discovered an updated variant that successfully infected 64-bit machines running Windows Vista or higher, while rendering 64-bit Windows XP and Server 2003 machines unbootable.
 
Normally, 64-bit Windows has several protections against untrusted modifications to the kernel, including a requirement that all drivers be signed, and PatchGuard, which prevents tampering of certain system structures.  Aside from intercepting the OS boot sequence early in the cycle, the malware also reconfigures the operating system in a visible way to accept loading of unsigned drivers.  Since the method used to do this is a supported extensibility feature of the kernel used by full disk encryption and compression software, it does not actually violate the guarantees PatchGuard provides about system integrity.
 
Blocking and Detection for this Threat
Proactive detection for this threat and the malware that tries to install it has been available since Aug. 6 for customers of Microsoft Security Essentials, Microsoft Forefront Client Security, Forefront Server Security, and the Forefront Threat Management Gateway:

 If you did not have proactive detection in place, you can (currently) manually check to see if the bootkit is installed.  As a side effect of the bootkit, the Disk Management pane of the Computer Management console will fail to show the system drive altogether:

It will also fail to show up in the command line  using diskpart:

As always, we strongly urge users to run the latest version and updated signatures of an Anti-Malware product such as Microsoft Security Essentials to provide proactive protection against this threat.

Jason Conradt, Jeremy Croy, Joe Johnson

Recently, my MMPC research colleague Michael Johnson blogged about an interesting social engineering technique that results in a malicious JavaScript being run on the unsuspecting recipient's computer when they follow the instructions provided in a .PNG image file. Unsurprisingly, we recently found that malware authors are using this PNG-to-BMP conversion process as a means of obfuscating their malicious code, without any user interaction.

Trojan:Win32/Sirefef.M belongs to a family of malware that is highly obfuscated, using multiple layers of encryption and a number of anti-debugging and anti-emulation techniques to avoid detection. If we step through a particular sample we found recently, downloaded by Win32/Oficla, we find a .PNG file underneath one layer of its encryption, as shown below:

If we view the .PNG in an image-viewer, we can see the image displays nothing of value, as seen in the screenshot below:

Win32/Sirefef.M proceeds to convert this image into a bitmap, which decompresses the image, producing more executable code for the trojan to execute, which is partially shown below stored by the trojan in a buffer:

Further analysis of this code reveals additional layers of encryption, before the malware's true payload is finally reached.

What is the malware's payload, you may ask? Previous variants of this family include functionality such as re-directing the user's Internet search results and generating pop-up ads. But this variant differs, revealing another interesting aspect of this particular piece of malware.

As part of its payload, Win32/Sirefef.M downloads a portable executable (PE) file from a specific IP address through port 8082. The PE, however, is simply a resource-only DLL, detected as Rogue:Win32/Sirefef, containing resources such as image files, JavaScripts and HTML files. If we look at one of the resources, we can see exactly what we are dealing with here:

Using all of these resources, Win32/Sirefef.M reveals its true colors, displaying the following fake scanning interface and exhibiting typical rogue behavior, calling itself "Antivirus 2010 Security Centre":

This method demonstrates a not-too-common approach by the rogue authors, where instead of packing all of the rogue's functionality and interfaces into the one executable, they store them in a remote location. They do this in a resource file, which can be easily updated with new interfaces, logos, buttons, scripts, etc; this can allow them to change the look of the rogue without having to make many code modifications to the downloader that loads it.

Thank you to Scott Molenkamp and Michael Johnson for their help in the analysis of this threat.

- Amir Fouda

MMPC Melbourne

Note: files analyzed include:
Sirefef.M, SHA1: 31827147766a65b9415345c71303274e256a2272
Rogue:Win32/Sirefef, SHA1: 67d85964352c45a649563fa139e8915537f58d78

This month’s Malicious Software Removal Tool (MSRT) release added new detection and cleaning for several malware threats that incorporate the use of the CVE-2010-2568 vulnerability (which was fixed by the MS10-046 security bulletin released in August).  This includes the Win32/Stuxnet family and several variants of Win32/Vobfus and W32/Sality.

From a global perspective, the results for these .lnk-related families were interesting.  The following chart shows countries with the most saturated infections—that is, for every computer scanned, what percentage had an infection for each family.

Although these families had large numbers of cleanings in places like the US, India, France, Russia, Spain, and Brazil, these locations were not nearly as saturated with the malware (when you look at infections per capita) in comparison to the top regions shown in the chart above.  Some regions had smaller numbers of affected computers, but extraordinarily high saturation rates, such as Iran and Indonesia.

Iran and Indonesia have typically had very low CCM rates.  (CCM stands for Computers Cleaned per Mille – a count of how many computers were infected for each thousand scanned.)  This count is a measure of all malware families, not just a single family.  The Stuxnet infections that Iran and Indonesia have incurred over these past few months have been high enough to triple their CCMs.  To have a single family increase a country’s typically low malware saturation by a factor of three is very significant.

The charts below show the top five locations were the most computers were cleaned by family along with the percentage of computers cleaned in comparison to the total number scanned by MSRT in that location (between the start of Aug. 10 and midnight, Aug. 17, 2010).

Stuxnet

Vobfus

 Sality.AU

In addition to these malware families, MSRT also cleaned any malicious links found on these systems in an attempt to stop the propagation vector, no matter what malware family may have incorporated it.

Top 10 families so far this month:

Within the first week of release, MSRT cleaned 12,283,167 files in 2,005,960 infected machines. Bubnix, the threat that was added last month to the MSRT, is currently the most-cleaned threat and is actually third on the list of the top 25 families from last month’s MSRT release.  It has been disinfected from 471,243 machines.

Top 10 threats so far this month:

Stuxnet, which led to the initial discovery of the CVE-2010-2568 vulnerability that allows shortcut files to automatically launch when a removable drive is accessed, has a disinfection count that is lower than other related families. At the moment, it has been disinfected from 46,351 machines (components like Trojan:WinNT/Stuxnet.A and Trojan:WinNT/Stuxnet.B are often found on the same computer). On the other hand, Win32/Vobfus, a family of obfuscated worms that has been around since 2009 but incorporated the vulnerability into several of its later variants, has a higher disinfection count compared to Stuxnet. Win32/Vobfus has been disinfected from 149,911 machines, mostly due to the Worm:Win32/Vobfus.gen!A variant. Sality is right behind Vobfus in terms of machine counts, coming in at 130,992 disinfected machines.

More reading about Stuxnet, Vobfus and other related stuff:

http://blogs.technet.com/b/mmpc/archive/2010/08/10/breaking-some-malicious-lnks-with-msrt.aspx
http://blogs.technet.com/b/mmpc/archive/2010/07/30/stuxnet-malicious-lnks-and-then-there-was-sality.aspx
http://blogs.technet.com/b/mmpc/archive/2010/07/23/protection-for-new-malware-families-using-lnk-vulnerability.aspx
http://blogs.technet.com/b/mmpc/archive/2010/07/16/the-stuxnet-sting.aspx

More about Bubnix:

http://blogs.technet.com/b/mmpc/archive/2010/07/14/bubnix-uses-interesting-obfuscation-scheme.aspx

Aside from the above mentioned threats, MSRT disinfected the usual game-password stealers such as Taterf and Frethog, several rogue threats including FakeSpypro and FakeXPA and other prevalent and familiar threats that we usually see.

- Francis Allan Tan Seng, Vincent Tiu, and Holly Stewart

Unruy is a family of trojan downloaders and unsolicited advertisement "providers" and although you might not have heard about it, it also is an infection vector for a rather prevalent family of rogues: Trojan:Win32/Fakespypro.

Recently we discovered a variant of Win32/Unruy, namely TrojanDownloader:Win32/Unruy.D (6120ac9c363c6da7cd7f8bed4edd314f0d3d8f4e), that is actively using the Java vulnerability discussed in CVE-2010-0094. The vulnerability exploits a flaw in the deserialization of RMIConnectionImpl objects. This flaw allows remote attackers to call, without proper sandboxing, system-level Java functions via the ClassLoader of a constructor that is being deserialized.

Infection can occur when a user visits a webpage that hosts a malicious Java applet. If the user’s browser runs a vulnerable version of the Java Runtime Environment (up to version 6 update 18), exploitation may be successful and malware may be installed.

We are currently detecting malicious applets that exploit this vulnerability as Exploit:Java/CVE-2010-0094.A and the bundled Java downloader component as Trojan:Java/Rowindal.A.

A security update for this vulnerability has been available since March 2010 and we suggest you apply it as soon as possible, if you haven’t already.

As good practice, we advise every user to always update their programs as well as their operating systems. We also advise users not to open files whose origins they don't trust.

Marian Radu
MMPC Dublin

The MMPC added the following MS10-046 related threats to the MSRT detection capability in August:

• Win32/Stuxnet
• Win32/CplLnk 
• Worm:Win32/Vobfus.gen!A 
• Worm:Win32/Vobfus.gen!B 
• Worm:Win32/Vobfus.gen!C 
• Worm:Win32/Vobfus!dll 
• Worm:Win32/Sality.AU 
• Virus:Win32/Sality.AU 
• TrojanDropper:Win32/Sality.AU 

Former blog posts have mentioned threats like Stuxnet, Vobfus, and Sality, which have incorporated the use of the CVE-2010-2568 vulnerability fixed by the MS10-046 bulletin (see timeline below). It’s clear that an increasing number of malware families are incorporating this vulnerability. Today’s MSRT release represents another step Microsoft is taking to cleanse the ecosystem of this infection vector.  If you happen to have declined MSRT update from Windows Update, you can download and run it from Microsoft Download Center.  For enterprise/WSUS users, refer to our KB article about how to deploy MSRT.
 

 
We highly encourage our readers to apply all security updates to protect themselves from this and other vulnerabilities.
 
One of the threats using this vulnerability that we recently discussed is Sality.  It is a virus (a.k.a file infector) and has the potential to infect many files on your computer, making the disinfection tricky and time consuming, since in many cases it must repair, not simply delete, the troubled files.  Recall that MSRT is a “cleanup” tool.  It does not provide Real-time protection. To protect from re-infection, a full AV product such as Microsoft Security Essentials is needed. 
 
Many thanks to our researchers Hamish, Vince, Francis, Hemanth, Mady, Jeremy, et al. for working around the clock to add the detections on all these threats.
 
-Scott Wu

The MMPC came across an interesting piece of social engineering today that embeds a malicious script, which has been observed circulating on 4chan message boards. On further investigation, it became apparent that this is the next stage in the evolution of a threat known as 4chan.js that has been around since 2008. This scenario relies on a user's trust of image file formats and an unfamiliarity of the .HTA format (by the way, HTA stands for HTML Application).
  
The user is sent a .PNG file that looks similar to the following screenshots: 

 
The .PNG file stores the data in a compressed format that is quite innocuous. Did you notice the fuzz at the bottom of the images shown above? This is actually compressed data that is stored in the image.
  
The following is a screenshot of the .PNG file as seen in binary: 

An interested user may follow the instructions in the .PNG and save the file as a bitmap (.BMP) with the .HTA extension. On doing this, due to the properties of the .BMP format, the file is now decompressed. It is then revealed that the file contains an image, some JavaScript, and one or more executable files. The newly formatted file is seen in the screenshot below:

Now, because the file is saved with a .HTA extension, upon execution the bitmap information will be bypassed, and the embedded JavaScript will be run.
  
In this case, the end result of all of this social engineering is for the family to repackage itself, beat the CAPTCHA mechanism employed by 4Chan, and send itself to the 4Chan bulletin board. We detect the dropped JavaScript as Trojan:JS/Chafpin.gen!A. We have now seen three versions of this trojan as the malware authors develop their methods. In the third method we saw, the bitmap was created with random variables each time it was run. Worth noting is that 4Chan are taking steps to prevent user infection by closing affected threads.
  
What is interesting about this file is the method of social engineering that the malware authors have employed. They are expecting the user to follow the instructions purely out of interest, to see what will happen. Most users are likely to trust an image format and might not realize that the same image file can contain an embedded malicious script.
  
Here at the MMPC we suggest that you do not follow the instructions of random pictures that you see, especially if the instructions involve altering the file in any way, and then running it. In fact, we would suggest just not running random .HTA files at all.
 
- Michael Johnson
MMPC Melbourne

Note: Analysed file details are as follows:
- .BMP SHA1 84c2689196903adb8bb3b904797754f6cbfe3b04
- .PNG SHA1 d0d8b26e9063a04f6d02efe429e31df7f0e10f65
- Dropped file SHA1 3b1b80b7a053d388a82a92eb590026e42f202280 

"Step-over" is a common feature of debuggers.  It allows us to avoid stepping into a subroutine, which is especially useful if the subroutine is thousands of lines long, or an operating sytsemsystem API, etc.  It also allows the user to (for some debuggers) step out of a loop or skip a repeated string instruction.  So what's the downside?  That depends on the debugger.

The most common attack against step-over involves self-modifying code, where the destination of the breakpoint is replaced by another instruction.  By stepping over the replacing instruction, the breakpoint is removed,removed and uncontrolled execution results.  The Obsidian Debugger and Titan Engine are vulnerable to the simplest implementation of that:

        mov b [offset l1], 0b0h
    l1: mov al, 1

This is of course unfair to Obsidian.  Obsidian is a "non-intrusive" debugger (unlike Titan Engine), which means that it does not attach to the process.  Instead, it allows stepping by reading and writing process memory, and placing "jmp $" instructions instead of breakpoints at the target address.  Thus, it is not designed to handle self-modifying code.

Of course, most debuggers aren't written that way, and they also don't use breakpoints for stepping over ordinary instructions, so some knowledge of a given debugger is necessary.  Unfortunately, Rock Debugger and FDBG are vulnerable to a simple trick: placing a "repeat" instruction in front of the replacing instruction, like this:

        rep
    l1: mov b [offset l1], 90h
    l2: nop

If a step-over is attempted at l1, then execution will resume freely from l2.  However, a more subtle attack is possible.  A debugger has no way of knowing if the breakpoint that it places at a location is the one that is executed.  If the application removes the breakpoint, it can also restore the breakpoint afterwards, and then jump to the address to execute that breakpoint.  The debugger will see the breakpoint exception that it was expecting to see, and behave as normal, like this:

        mov al, 90h
    l1: xor ecx, ecx
        inc ecx
        mov edi, offset l3
    l2: rep stosb
    l3: nop
        cmp al, 0cch
    l4: mov al, 0cch
        jne l1
    l5: ...

In this example, stepping over the instruction at l2 will allow the code to reach l4.  This will cause the breakpoint to be replaced by l2 and executed by l3.  The debugger will then regain control.  At that time, the only obvious difference will be that the AL register will hold the value 0xCC instead of 0x90, and which will allow l5 to be reached in what appears to be one pass instead of two.  Of course, much more subtle variations are possible, including the execution of entirely different code-paths.

On the other hand, an indirect call that points directly to a "return" instruction should be safe to step over, right?  Not in OllyDbg.  It's possible to construct a sequence such that stepping over the call will cause uncontrolled execution!  Turbo Debug32 has a similar problem, but it's not the special call->ret sequence that's at fault.  Instead, it's the fact that Turbo Debug32 miscalculates the length of certain call instructions (a variation of a bug that I have described last year in a paper), allowing a jump instruction to be inserted after the call, which is not "seen" by the debugger.  By stepping over the call, the jump is reached and executed instead of the breakpoint, resulting in uncontrolled execution.

WinDbg is not vulnerable to these attacks, but it is vulnerable to a detection method because of how it implements step-over for instructions with certain prefixes (or, in this case, redundant prefixes).  The problem is that WinDbg uses the single-step method to step over instructions with redundant prefixes.  If the instruction being stepped over is the pushfd instruction, then the T flag will be saved on the stack image, and WinDbg cannot prevent that from occurring, like this:

    cs:cs:pushfd
    pop  eax
    test ah, 1
    jne  being_debugged

Even debuggers have bugs.

- Peter Ferrie

Today, Microsoft announced plans to release of an out-of-band update to address CVE-2010-2568 (described in Microsoft Knowledge Base Article (2286198)).  As mentioned earlier this month, the Microsoft Malware Protection Center (MMPC), along with other Microsoft Active Protection Program partners, have been keeping a close watch on the use of .LNK files exploiting this vulnerability. As with many new attack techniques, copycat attackers can act quickly to integrate new techniques.  Although there have been multiple families that have picked up this vector, one in particular caught our attention this week– a family named Sality, and specifically Sality.AT.  Sality is a highly virulent strain.  It is known to infect other files (making full removal after infection challenging), copy itself to removable media, disable security, and then download other malware.  It is also a very large family—one of the most prevalent families this year.  After the inclusion of the .LNK vector, the numbers of machines seeing attack attempts combining malicious .LNKs and Sality.AT soon surpassed the numbers we saw with Stuxnet.  We know that it is only a matter of time before more families pick up the technique.

The following *chart shows this trend:

These numbers show infection attempts upon systems we protect (Microsoft Security Essentials, Microsoft Forefront Client Security, Windows Live OneCare, the Forefront Threat Management Gateway, and the Windows Live Safety Platform).  Even though they do not represent the number of actual infections, these attack attempts indicate when threats are becoming more widespread.

Another indicator that other families are picking up this exploit is the change in the geolocation of the attack attempts.  Brazil had seen very little attack attempt activity when Stuxnet was initially discovered, but an analysis of the change in geolocation for CVE-2010-2568 attack attempts shows how Brazil and other countries are now seeing much more activity.  Sality, in particular, has historically had a heavy presence in Brazil.

Although there are likely other threats that have integrated this technique, many of the samples we have seen so far are detected by our existing family signatures.  Signatures covering related threats we have confirmed are listed below.  These signatures are available for customers of Microsoft Security Essentials, Microsoft Forefront Client Security, Windows Live OneCare, the Forefront Threat Management Gateway, and the Windows Live Safety Platform.

Malicious links exploiting CVE-2010-2568
Exploit:Win32/CplLnk.A
Exploit:Win32/CplLnk.B

Stuxnet
TrojanDropper:Win32/Stuxnet.A
Trojan:WinNT/Stuxnet.A
Trojan:WinNT/Stuxnet.B (initially called VirTool:WinNT/Rootkitdrv.HK)
Trojan:Win32/Stuxnet.A
Worm:Win32/Stuxnet.A
Worm:Win32/Stuxnet.B

Sality
Virus:Win32/Sality.AU (initial detection provided by generic signature Virus:Win32/Sality.AT)

Vobfus
Worm:Win32/Vobfus.H
Worm:Win32/Vobfus.P

Chymine
Trojan:Win32/Chymine.A
TrojanSpy:Win32/Chymine.A
TrojanDownloader:Win32/Chymine.A

* Charts above were updated to indicate data since July 28, 2010 and through midnight July 29, 2010.

-- Holly Stewart, MMPC

"Adun Toridas!"
 
Starcraft fans would recognize that as a famous line from the first Starcraft version, which was released in 1998. Starcraft is a real-time strategy game that became a massive hit worldwide. The release date for its sequel, Starcraft II: Wings of Liberty, is today, the 27th of July. Players can install the game but can only activate their licenses from this day onwards. Surely most gamers out there (including us) are eager to get their hands on this new title, especially if you were a fan of the first.
 
Here in the MMPC, we monitored this event as malware writers almost always attempt to take advantage of high-profile news, this being a prime example. Sure enough, we found samples that pretend to be Starcraft-related files but are actually malware.
 
For instance, "Starcraft_II.exe" (Sha1: ae648158b87d1513d2777ddb2233d3e83e2741c9) contains a file named "WinUpdate.exe", which is actually malicious and is detected as VirTool:Win32/VBInject.gen!DM. This is a generic detection for Visual Basic-compiled files that attempt to load other malware by injecting code into different processes.
 
Another interesting file we saw is "StarCraft.2.Wings.Of.Liberty.CLONEDVD-WW TRAINER.exe" (Sha1: fdaa5abd53256a3fb0ddca5d3dead622768b3ab2). We detect this file as Worm:Win32/Rebhip.A. After a bit of research, we found that it is available to download through the BitTorrent protocol. Worm:Win32/Rebhip.A is a worm capable of stealing sensitive information from your computer by logging keystrokes and gathering passwords.
 
Enjoy playing, as "we are vigilant" for any "nuclear launch malware detected."
 
--Andrei Saygo & Francis Tan Seng

We’ve added detection for two new malware families using the vulnerability described in SA2286198. The first, Win32/Vobfus, is actually a family of obfuscated worms that has been around since 2009. According to our fellow researcher Marian Radu, who named the family, the name was derived from the fact that the worm is coded in Visual Basic (VB) and is highly obfuscated:

V(isual Basic) + obfuscated = Vobfus

We need to emphasize, however, that the first Vobfus samples that we’ve seen using the shortcut vulnerability have only emerged in the past few days. Previous samples of Vobfus DO NOT exploit the vulnerability. The first Vobfus variant to do so is Worm:Win32/Vobfus.H.

Vobfus and shortcut files have a longstanding relationship: this family has, from the beginning, been using shortcut files as a social engineering technique to get users to run its code. However, these shortcut files DID NOT automatically run. Rather, Vobfus also drops an autorun.inf file to run its copy in the drive if Autorun is enabled (see how to disable Autorun in your Windows computer). New samples of Vobfus.H, however, as we previously mentioned, drop a specially-crafted, malicious shortcut file that exploits the vulnerability discussed in SA2286198. We detect these malicious links as Exploit:Win32/CplLnk.B; the same detection as some of the shortcut files associated with the vulnerability exploited by the Stuxnet family.

The other new malware family that we’ve seen associated with the shortcut vulnerability is Chymine, the dropper component which we’ve seen launched by a specially-crafted, malicious shortcut file that exploits SA2286198. In this case, Trojan:Win32/Chymine.A is launched by a malicious shortcut that we detect as Exploit:Win32/CplLnk.A. It, in turn, drops another trojan we detect as TrojanSpy:Win32/Chymine.A, which we’ve observed to be logging user keystrokes and downloading other malware. Aside from that, it seems to be just another malware that exploits a new attack vector. We’re keeping an eye out for this family and other potential malware that may be using the same vector.

What we’re seeing with the use of this new vulnerability by two other malware families is typical when an exploitable vulnerability is made public: initially, details emerge about a proof-of-concept malware or a targeted attack, then someone releases a public exploit, then the exploit gets incorporated into malware crime kits, and then we begin seeing different families using it.

So what can users do in the meantime? The MMPC has released detection for all of the currently known Stuxnet, Vobfus, and Chymine malware, so make sure that you have the latest definitions if you are using a Microsoft antivirus solution.  If you don’t antivirus protection, consider installing Microsoft Security Essentials. An option to prevent exploitation of the vulnerability is to disable displaying shortcut icons; there’s a Microsoft Knowledge Base Article (2286198) outlining exactly how to do that. And if you suspect that you have a malicious file in your computer, whether or not you think it exploits the vulnerability discussed in SA2286198, we encourage you to send us a sample.

Worm:Win32/Vobfus.H
127f24a7ba42e6f31e9b4044555898fded211de8
5a474fa6e79b80145b06762a5c795f3e197d350a

TrojanSpy:Win32/Chymine.A
42e7a0dba9ddb5ec0101dc26bf6d989834488b7c
bd4c09d2431e31aff6b397e38fc67845174c3d74

-- Francis Allan Tan Seng & Elda Dimakiling

For the past week or so, we've been closely tracking a new family of threats called Stuxnet (a name derived from some of the filename/strings in the malware - mrxcls.sys, mrxnet.sys).  In the past few days, it has become a  popular topic of discussion amongst security researchers and in the media. First and foremost, we have recently released one additional signature for this threat, and urge our readers to be sure that you've got the latest anti-malware definition updates installed.

Prevalence and distribution

In terms of numbers of attacks, the most reports are coming from the US, Indonesia, India, and Iran.  When you factor in the number of MMPC monitored machines along with the number that are reporting attacks, the US falls further down the list, giving way to Iran and Indonesia with attack attempts far higher than the global average.

Figure 1: Geographic saturation of Stuxnet infection attempts

Although the number of new machines reporting an infection attempt has remained constant at around a thousand per day, the number of attempts (tries per machine) has increased over the past few days:

Figure 2: Threat prevalence

Hacker exchange

In addition to these attack attempts, about 13% of the detections we’ve witnessed appear to be email exchange or downloads of sample files from hacker sites.  Some of these detections have been picked up in packages that supposedly contain game cheats (judging by the name of the file).

Threat details

What is unique about Stuxnet is that it utilizes a new method of propagation. Specifically, it takes advantage of specially-crafted shortcut files (also known as .lnk files) placed on USB drives to automatically execute malware as soon as the .lnk file is read by the operating system. In other words, simply browsing to the removable media drive using an application that displays shortcut icons (like Windows Explorer) runs the malware without any additional user interaction. We anticipate other malware authors taking advantage of this technique. Stuxnet will infect any usb drive that is attached to the system, and for this reason we’ve classified the malware as a worm.  This classification for the malware should not be confused with another vector used by this worm, the newly disclosed vulnerability (CVE-2010-2568) covered in today’s advisory.  The vulnerability itself is not wormable.

Stuxnet uses the aforementioned .lnk technique to install additional malware components.  It first injects a backdoor (Worm:Win32/Stuxnet.A) onto the compromised system, and then drops two drivers:

• Trojan:WinNT/Stuxnet.A - hides the presence of the .lnk files
• Trojan:WinNT/Stuxnet.B - injects (formerly) encrypted data blobs (.tmp files) into memory, each of which appear to serve different purposes as the Stuxnet deployment system infrastructure (drivers, .lnk files, propagation, etc.).

These drivers are signed with a digital certificate belonging to a well-known hardware manufacturer called Realtek Semiconductor Corp., which is unusual because it would imply that the malware authors somehow had access to Realtek’s private key.  Microsoft MMPC has been working with Verisign to revoke this certificate, and did so at 08:05:42 PM UTC with the agreement and support of Realtek.

Threat prevention

We have multiple signatures that detect this threat for customers using Microsoft Security Essentials, Microsoft Forefront Client Security, Windows Live OneCare, the Forefront Threat Management Gateway, and the Windows Live Safety Platform. In addition to using antimalware technology, MSRC has released an advisory with work-around details.

Initial malware (the dropper):
TrojanDropper:Win32/Stuxnet.A

Malware the dropper attempts to drop onto the system:
Worm:Win32/Stuxnet.A
Trojan:WinNT/Stuxnet.A
Trojan:WinNT/Stuxnet.B (initially called VirTool:WinNT/Rootkitdrv.HK)
Trojan:Win32/Stuxnet.A
Worm:Win32/Stuxnet.B

Attack vector (.lnk files):
Exploit:Win32/CplLnk.A (added recently – versions 1.87.24.0+)

We suspect that Stuxnet has been active for at least a month, possibly longer... we have detection for it and its various components and will keep you posted with developments as our talented researchers (like Matt McCormack, Holly Stewart, Peter Ferrie, Patrick Nolan, Andrei Florin Saygo and Francis Allan Tan Seng) continue tracking this threat.

--Tareq Saade

This month, we added the Bubnix family to the latest Malicious Software Removal Tool (MSRT) release.

WinNT/Bubnix is a complicated spam bot which arrives on an affected computer by way of a downloader, TrojanDownloader:Win32/Bubnix.A. TrojanDownloader:Win32/Bubnix.A is itself often downloaded by variants of Win32/Bredolab and Win32/Harnig in the wild.

Generally speaking, it is common for a malicious executable to be transferred in encrypted form by a downloader. In order to increase the apparent legitimacy of the content,
TrojanDownloader:Win32/Bubnix.A takes this a simple step further. Let us take a look at what the Bubnix downloader retrieves below:

Figure 1. Content retrieved by the Bubnix downloader

Upon cursory inspection, this appears to be a 'Rar' archive. In fact, the header is a valid one for a password protected archive. Any attempt to "decompress" the archive will yield a request for the password. This isn't really a true 'Rar' archive. Let us now take a closer look at the downloader itself:

Figure 2. Bubnix downloader code

We can see from this, if what appears to be a 'Rar!' marker is found, the key and length are then extracted. This information is passed to a decryption function, where the malicious Bubnix driver is revealed. The highlighted portion in Figure 1. at offset 0x14 is the decryption key.

Beyond simple transformation, there are many and varied techniques used by malware to mask and encapsulate the content of transmissions. Whether it is a malicious binary, command and control directives or sensitive data, there is always something new to examine.

- Scott Molenkamp

Just a quick post here to provide an update on the attack attempts related to the Help and Support Center vulnerability and to stress the importance of applying the critical update made available today, MS10-042, which fixes the issue for the two vulnerable operating systems, Windows XP and Windows 2003.
 
A few weeks ago, MMPC reported seeing automated attacks that were identified by the signatures we had deployed in our protection products.  These attack attempts have continued to expand and some new attack patterns have come into play.  The attacks that we have witnessed in the wild work only on Windows XP (not Windows 2003).  Early on, we saw attackers incorporate code to single out Windows XP targets, but more recently the attackers have been less discriminant, attempting this attack on a variety of operating systems, about half of which were not susceptible because the exploit code could have only been successful on a vulnerable version of Windows XP.
 
As of midnight on July 12 (GMT), over 25,000 distinct computers in over 100 countries/regions have reported this attack attempt at least one time.  The chart below shows a fairly large increase over this past weekend, shortly after the MSRC announced that an update would be provided to fix this issue with the July security bulletin release.


 
These reports come from machines using our protection products and services, such as Microsoft Security Essentials, Microsoft Forefront Client Security, Windows Live OneCare, the Forefront Threat Management Gateway, and the Windows Live Safety Platform.  For more information about the signatures that detect this exploit and payloads delivered by it, see the previous post on this topic.
 
Changes in Country/Region Distribution

Although Portugal has remained one of the most targeted areas, attacks on Russian systems have surpassed it over the past few weeks.  Russia has now seen more than ten times the number of attack attempts per computer in comparison to the global average.  Other countries/regions that have seen more than the global average are predominantly in Europe and the UK.  The UK, in particular, was one of the regions in which we witnessed a surge in attack attempts over this past weekend.


 
Considering MMPC has received telemetry on attack attempts in over 100 countries/regions, we recommend that everyone—regardless of their location—apply MS10-042 today on any of their systems running Windows XP or Windows 2003. 

-Holly Stewart, MMPC

Often you read about how, during major news events, the bad guys have commandeered the search engines so if you go looking for more information about the news event, you end up at a page that’s serving you some malware nowadays -- usually some kind of fake antivirus program.  But how did the bad guys fake out the search engines to get their sites so high in search to get people to click on them?  Let me explain, using a spamming shoe seller as an example of the technique.

First, I have a Twitter account through which I tweet security related news.  In order to find such news items, I have alerts set up to inform me of such news, which I cull for something interesting.  One such alert was this:

The story looks real.  It’s a blog and it’s about how employees of merchants read the details off a credit card to make a duplicate card and make use of it.  The only thing strange would be the reference to a name brand sneaker.

But when you go to read the article, it appears like this:

The origin of the article is unknown as searches on the Internet are crowded out by other cases of this article being used for SEO poisoning in favor of other sites.

What you notice though (magnified above) is that sprinkled into this version of the article are numerous links to a site selling shoes.  (You can see part of the URL in the bottom left of the screen capture.)

So, how does SEO work?

Online marketers have a financial motivation to getting their wares before your eyes.  One of the best ways today is to get their site high up on the list of sites you would encounter if you were to search for an item that they sell.  So, they learn what it takes to score high in the search engine scoring formula. The less ethical ones will even, as you see, try to get high up on the list of search results by hijacking popular topics that have nothing to do with whatever they’re selling.

What we’ve seen in this example:

• Starting with a topic that has high interest: Credit card fraud.  Their article will get picked up and read, raising the value of such pages.  (And unfortunately, my clicking and reading their page raises their value.)
• On that page, there are links to their websites that sell their shoes.  Since, this page is so interesting, and it points a number of times to their sales page, that sales page must also be very interesting, or so think the search engines. 
• People who search for Nikes are also likely to search for Pumas, and so with both in context, this page gets even more interesting.

And the result of all this is, the page that sells their shoes gets a good score.

What happens now when you search for “puma shoes”?

First result shown by many popular search engines is the set of sponsored sites, companies that have paid the search engine to be listed first.  Then comes the official website for Puma.  And top amongst the rest?  There it is!  The site involved in the SEO I’ve just described.  (The result above was captured early morning, July 8, 2010.)  On another search engine, first and second were the same (as expected) and this site was second among the rest.

I tried the same search using Bing and found the poisoned result relegated all the way to page 6. While I did not work with the Bing team in this particular situation, we do cooperate with them and inform them of any cases where we discover malware being hosted so they don’t offer those sites to their customers, just as we cooperate with the SmartScreen folks to help Internet Explorer block malware sites.

The SEO example I’ve just shown you is not one that leads to malware, but the technique is the same. In order to capture the highest rankings for current event topics, the sprinkling of words would be the likely phrases being used to search for the latest news, which you can also happen to find from the search engine trends.  And so, effectively, SEO of current events terminology is accomplished the same way.

One final note for the above site.  The owner uses a fake US address and has a phone number registered for the site.  The phone number is in Mexico.

-- Jimmy Kuo

We've been monitoring for active attacks on the Windows Help and Support Center vulnerability (CVE-2010-1885) since the advisory was released on June 10th.  At first, we only saw legitimate researchers testing innocuous proof-of-concepts.  Then, early on June 15th, the first real public exploits emerged.  Those initial exploits were targeted and fairly limited.  In the past week, however, attacks have picked up and are no longer limited to specific geographies or targets, and we would like to ensure that customers are aware of this broader distribution.  If you have not yet considered the countermeasures listed in the Microsoft Security Advisory (2219475), you should consider them.

As of today, over 10,000 distinct computers have reported seeing this attack at least one time.  Here are some details on the attacks we're seeing.

Geolocation

• The largest targets in terms of attack volume have been the United States, Russia, Portugal, Germany, and Brazil.
• A regional saturation rate, the number of attacked computers per a population of monitored systems (counted using a unique identifier), shows a slightly different picture.  In this aspect, Portugal has seen a much higher concentration of attacks - more than ten times the world-wide average per computer.  Russia is second at eight times the world-wide rate.

Attack Proliferation
Starting last week, we started seeing seemingly-automated, randomly-generated html and php pages hosting this exploit.  This attack methodology constitutes the bulk of attacks that have continued to flourish into this week.  The following chart shows the timeline of the proliferation:

Payloads of the Exploit
At first, the attacks seemed to focus on downloading Obitel, which is malware that simply downloads other malware.  However, most recently, downloads have run the gamut, varying in methodology (some direct downloads, but also some downloads involving single or double script redirects, which our products detect as TrojanDownloader:JS/Adodb.F and TrojanDownloader:JS/Adodb.G, and also varying in payload.  The following list shows some of the payloads we've detected:

• Trojan:Win32/Swrort.A
• TrojanDownloader:Win32/Obitel.gen!A
• Spammer:Win32/Tedroo.AB
• Trojan:Win32/Oficla.M
• TrojanSpy:Win32/Neetro.A
• Virus:JS/Decdec.A

Protection
In addition to the mitigations listed in the advisory, customers using Microsoft Security Essentials, Microsoft Forefront Client Security, Windows Live OneCare, the Forefront Threat Management Gateway, and the Windows Live Safety Platform have had coverage for this exploit since June 10th through the following two antimalware signatures:

• Exploit:Win32/CVE-2010-1885.A
• Exploit:Win32/CVE-2010-1885.gen
  Signature builds 1.83.1561 and later contain both signatures.

Payloads are detected by the signatures mentioned above.

We’ll continue to monitor this situation and provide updates as appropriate.  Special thanks goes to Lena Lin, Rodel Finones, Chengyun Chu, and Chris Stubbs for doing detailed analysis on these attacks and how these exploits are attempting to deliver malware.

- Holly Stewart, MMPC

It's been ten years since I first noticed the word "callback" in the Thread Local Storage (TLS) section of the Portable Executable format documentation. Since then, we've seen it used and abused by virus writers, packer vendors, and general mischief-makers (and me, too, of course, as part of my research). During that time, I thought that I had discovered everything that there was to know about it. Apart from the fact that it runs before the main entrypoint, there are other things that it can do:

• The TLS callback array can be altered (later entries can be modified) and/or extended (new entries can be appended) at runtime.  Newly added or modified callbacks will be called, using the new addresses. There is no limit to the number of callbacks that can be placed.
• TLS callback addresses can point outside of the image, for example, to newly loaded DLLs. This can be done indirectly, by loading the DLL and placing the returned address into the TLS callback array. It can also be done directly, if the loading address of the DLL is known. The imagebase value can be used as the callback address, if the DLL is structured in such a way as to defeat DEP, in case it is enabled, or a valid export address can be retrieved and used.
• TLS callback addresses can contain RVAs of imported addresses from other DLLs, if the import address table is altered to point into the callback array. Imports are resolved before callbacks are called, so imported functions will be called normally when the callback array entry is reached.
• TLS callbacks receive three stack parameters, which can be passed directly to APIs. The first parameter is the ImageBase of the host process. It could be used by APIs such as the kernel32 LoadLibrary() or kernel32 WinExec() functions.  The ImageBase parameter will be interpreted by the kernel32 LoadLibrary() or kernel32 WinExec() functions as a pointer to the file name to load or execute. By creating a file called "MZ[some string]", where "[some string]" matches the host file header contents, the TLS callback will access the file without any explicit reference.  Of course, the "MZ" portion of the string can also be replaced manually at runtime, but many APIs rely on this signature, so the results of such a change are unpredictable.
• TLS callbacks are called whenever a thread is created or destroyed (unless the process calls the kernel32 DisableThreadLibraryCalls() or the ntdll LdrDisableThreadCalloutsForDll() functions).  That includes the thread that is created by Windows when a debugger attaches to a process. The debugger thread is special, in that its entrypoint does not point inside the image. Instead, it points inside kernel32.dll.  Thus, a simple debugger detection method is to use a
• TLS callback to query the start address of each thread that is created.
• Since TLS callbacks run before a debugger can gain control, the callback can make other changes, such as removing the breakpoint that is typically placed at the host entrypoint.  When combined with the ntdll DbgBreakPoint() function patch, the result is a file that cannot be debugged by ordinary means. The debugger will attach to the debuggee, and then wait for the exception, which never occurs. Using Ctrl-C to break in will work well enough to look at the code, but breakpoints that are placed within the other threads will not activate.

The execution of TLS callbacks is also platform-specific. If the executable imports only from either ntdll.dll or kernel32.dll, then callbacks will not be called during the "on attach" event when run on Windows XP and later.

That should just about cover it, except for one thing. I was asked recently about some internal details regarding TLS callbacks in DLLs. Since I didn't have any test files easily accessible, I created a new one.  It was essentially a do-nothing file that contained a TLS callback. Then I created an .exe file and statically linked my test DLL to it. I tried to run the .exe file, and saw a message that it failed to load.  Okay, something wrong in my hand-crafted DLL.  The most likely reason is that I put a byte in the wrong place. The simplest way to find out is to step through loading the DLL dynamically, to see where it's failing, so that's what I did.  I created a new .exe file, which loaded the DLL dynamically, and then I stepped through the LoadLibrary() function code...

Imagine my surprise when I saw the loader examining the TLS data.  Why surprise?  Well, because it directly contradicts the existing Portable Executable format documentation. The documentation states that "Statically declared TLS data objects", that is to say, Thread Local Storage callbacks, "can be used only in statically loaded image files. This fact makes it unreliable to use static TLS data in a DLL unless you know that the DLL, or anything statically linked with it, will never be loaded dynamically with the LoadLibrary API function". However, in Windows Vista and later versions, the kernel32 LoadLibrary() function does call Thread Local Storage callbacks in DLLs.  Further, the Thread Local Storage callbacks will be called, no matter what is present in the import table. Thus, the DLL can import from ntdll.dll or kernel32.dll or even no DLLs at all (unlike the .exe case described above), and the callbacks will be called!

This is a significant change in behaviour.  It also leads to a very neat anti-emulator trick. This behaviour can be detected most easily by an .exe file that co-operates with the DLL. However, it is possible for a DLL to determine if it was loaded statically or dynamically by examining, for example, the value of the stack pointer or the Structured Exception Handler frame list, among other things. That would allow the .exe file to remain unaware of the behaviour, such as the case of an existing DLL being altered to provide this behaviour.

Example code for the DLL file TLS callback looks like this:

inc b [offset l1]
...
l1: db  0 ;set to 1 on attach
export l1

Example code for the .exe file looks like this:

push  offset l2
call  LoadLibraryA
push  offset l3
push  eax
call  GetProcAddress
xchg  ebx, eax
call  GetVersion
cmp   al, 6 ;Vista+
setnb al
cmp   , al
jne   being_emulated
...
l2: db   "mydll", 0
l3: db   "l1", 0

In this example, if the callback is called (presumably by the kernel32 LoadLibrary() function), then the value at l1 will be set to one. If the Windows version suggests Windows Vista or later, then a flag will be set to one. If the callback is not called, then the value at l1 will remain zero. If the Windows version suggests Windows XP or earlier, then a flag will be set to zero. If the two results match (either both set or both clear), then the expected behaviour has been demonstrated.  Otherwise, the presence of the emulator is revealed.

Oh yes, the problem with my DLL was that the TLS data pointer was off by one byte, resulting in a crash. That's why the DLL didn't load.

Oops.

- Peter Ferrie

A recently discovered backdoor sample (detected as Backdoor:Win32/Yonsole.A) can accept and execute a command from a remote server to modify the Master Boot Record (MBR) on the affected machine. The modification to the MBR is like the old "Stoned" virus for DOS. However, in this case, the MBR (the code is shown in Figure 1) does nothing but display a banner in the center of the screen and freeze the PC (figure 2). We detect the new MBR as Trojan:DOS/Yonsole.A.

Figure 1: The MBR code.

Figure 2: The screenshot of bootup.

--Chun Feng

Almost a year ago, I wrote a blog on promoting the use of telemetry when anti-malware testers compile their set of malware to run tests.  I thought it might be time to give people an update.

Basically, changing testers’ habits is like the proverbial turning of a battleship.  Testers use tried and true methodology.  And it’s important for the consumers of the test results to have consistent methodology to compare past results with present ones to build a pattern of progress.  So, even to improve the tests, it has to be done delicately and with broad support, and sound reason.

I believe I gave sound reason in the presentation last year.  Fundamentally, let’s make tests more meaningful for the average consumer.  And our initiative would be through telemetry because that’s what Microsoft would be best able to provide.

The broad support from industry came in the form of an IEEE effort resulting in the release of a standard for the sharing of malware metadata.  At the same time, a large percentage of the industry banded to form the Anti-Malware Testing Standards Organization (AMTSO).  AMTSO also works towards bettering tests.  Microsoft was a member at inception.  But it became clear that Microsoft’s objective of improving tests would be better served if we concentrated on one singular message (telemetry in testing) than to spread our voice behind the many efforts that AMTSO and its members would endeavor to accomplish.  (We respect the efforts and messages undertaken by AMTSO and will try to join its membership again at a reasonable time in the future.)

So, we were down to helping the testers.

Also around this time, Virus Bulletin (VB) was introducing a new component of their bimonthly testing called RAP tests (Reactive and Proactive).  In this test, VB would collect four weekly sets of malware samples to use in the test.  Tony Lee and I worked with John Hawes (VB’s Technical Consultant & Test Team Director) to show him the kind of data Microsoft could provide, and offered ways to interpret the data so more contributors could be engaged with similar data, so Microsoft would not bias the test by being the sole or dominant provider of such information.  John wrote:

We plan to do some prioritization of our own, aligning our sample selection processes with the prevalence data we gather from a range of sources – the aim being to include the most significant items... We continue to seek more and better prevalence data to add to our incoming feeds.- http://www.virusbtn.com/vb100/vb200902-RAP-tests

AV-Comparatives.org is an Austrian non-profit testing organization.  Starting with their February 2010 tests, they wrote:

You will notice that this time the test-set is smaller… This is because we are now trying to include in the test-set mainly prevalent real-world malware…  To build the test-set we consulted metadata and telemetry data collected and shared within AV industry…  Malware we see on user PC’s are automatically considered as important. - http://www.av-comparatives.org/images/stories/test/ondret/avc_report25.pdf

And for the most recent test released this month:

We tried to include in the test-set only prevalent real-world malware that has not been seen before the 10th February 2010 by consulting telemetry / cloud data collected and shared within the AV industry.  Consulting that data was quite interesting for us, as it showed that, while some vendors had seen some malware already many months or even years ago, the same malware hashes appeared in some other vendors clouds only recently. - http://www.av-comparatives.org/images/stories/test/ondret/avc_report26.pdf

Microsoft is one of the companies helping AV-Comparatives. I presume the other participants in the IEEE metadata telemetry effort are also involved, as having only one telemetry source is not sufficiently meaningful.  For, there is a saying in the field of telemetry gathering, “You can only see what you’re looking for.”  So, it’s important that telemetry be gathered from multiple sources.  Unfortunately, as yet there are still not a very large number of companies providing actionable telemetry to testers.  As a result, current telemetry primarily provides a negative use, rather than a positive one.  (Not negative-as-in-bad / positive-as-in-good; “negative” as in the telemetry is used to eliminate samples, not so much to assert samples as important.  Which is why AV-Comparatives makes the statement that malware they see on user PC’s are what they deem to be important.)

There is also a side-effect to the use of negative telemetry.  As noted before, since you can only see things you’re looking for, “no telemetry” does not mean the malware is less common than malware with low telemetry.  In fact, the side-effect occurs such that the detection score for a product that contributes telemetry is more likely diminished because samples they know, but are of low telemetry are the ones removed from the test set.  Or, as with the second AV-Comparatives quote above, samples known to exist prior to the cutoff date are removed.  And samples not known, stay in the test set.  So, during this early period of the adoption of telemetry, we are able to remove truly meaningless samples.  But, the products represented by those that contribute telemetry suffer a minor detection score deficit.

End result though, we know telemetry produces more meaningful test sets thus more meaningful tests.  And that benefits users.  So, we ask all products to join in contributing malware and metadata telemetry to testers.

This concludes part 1.  In part 2, I will talk about full product testing and false positives.

-- Jimmy Kuo

PS. We’re proud to note, even with the potential handicap, Microsoft Security Essentials was able to achieve the highest rating of Advanced+, with “very few” false positives in that latest AV-Comparatives test.

This month we add the rogue security program that we call Win32/Fakeinit to the list of malware families removed by MSRT. David wrote about Fakeinit a few months ago and it hasn't really changed since then. It's still calling itself "Internet Security 2010" and "Security Essentials 2010". We should expect to see "Security Essentials 2011" to show up soon.

Fakeinit uses the old one-two punch of first trying to convince you that there's malware all over your system, then offering a scanner that can detect and remove it - once you pay. Fakeinit separates these functions into two components. The first component changes the desktop background to something like this:

This component also terminates a whole bunch of programs as soon as they run. It doesn't do this to protect itself - the programs it kills include calc.exe, word.exe and freecell.exe - but rather to convince you that you are infected and generally make the machine hard to use in the hope of annoying you into paying for the scanner. Of course, Fakeinit downloads and installs the "scanner" (the second component) for you. The scanner reports more infections and tells you how to fix them by giving your money away.

If you do decide to pay, you're giving away not just your money, but also some pretty sensitive information including your name, address and credit card details. The page is not secured, meaning these details could be intercepted, but the real question is "what else will the makers of Internet Security 2010 do with this information?"

At best, you are likely to be charged more than you expected. Hidden at the bottom of the page, below the "proceed payment" button, are options for a "lifetime license" and "firewall and email protection" that are already selected for you. Together they add another $39.90 to the price. This is another classic rogue trick.

Fakeinit is also known to download Win32/Alureon, but in the MMPC lab these days we often say that "everything downloads Alureon". This isn't true of course, but it seems that way at times - Alureon is undoubtedly installed by more distinct malware families than anything else.

-- Hamish O'Dea

Recently Samsung released a new cell phone, the Wave, with a microSD card infected with malware.  The malware itself doesn't run on the phone, but does try to infect your computer. One could speculate that the imaging computer used to manufacture the first run of SD cards was infected and further spread the infection to customer computers.

It appears that this malicious software was distributed only to a limited number of customers and was isolated to a specific geographic region east of Spain and west of Poland.

We detect this malware as Worm:Win32/Verst.A.

In addition to being a worm, Verst.A searches for credentials and software registration details from a variety of applications including Miranda ICQ, WebMoney, QIP Infium, and Multi Password Recovery. We find it interesting that this threat searches for saved credentials from another password recovery tool. For more information, please view our detailed analysis available at:
http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=Worm:Win32/Verst.A

Verst.A spreads by taking advantage of the autorun feature in Windows. If run, the worm starts a thread that continuously tries to copy itself to all drives from A to Z. Fortunately Windows 7 will prompt users before invoking autorun.  Also, you can update your autoplay functionality on other Windows versions by following the instructions here.

If you suspect that you're infected, we suggest that you scan your system for malware using a credible scanner such as Microsoft Security Essentials.

- Dan Kurc & Tim Liu

The FBI announced today federal indictments against those allegedly involved in the distribution of the WinFixer family of malware.  WinFixer is a form of software often referred to as “rogue security software” or “scareware”. WinFixer  is, essentially, software which fraudulently purports to provide a security benefit and in exchange solicits credit card information in order to charge the victim for a full version which will clean up infections which may not even be present.  This family of malware displayed a number of different names in its attempts to social engineer its victims and appear legitimate. Some of the names associated with this family include Antivirus 2008, Antivirus 2009, WinSpywareProtect, Spyware Isolator, Advanced Cleaner, Antivirus XP and others.

The Microsoft Malware Protection Center provided support for our Digital Crimes Unit in the investigation of WinFixer and would like to commend them as well as the Department of Justice and FBI for their actions in helping to protect our customers.

You can read more about this in the Microsoft On The Issues blog here.

--Jeff Williams
Principal Group Program Manager, MMPC

Last week, I was checking my Facebook account and noticed I had an Event Invitation from a fellow security researcher. Very intriguing. This friend is a world traveler and doesn’t currently reside in the United States, but the Event Invitation was for a Free $1000 "Best Buy gift card to celebrate Best Buy’s 20th Anniversary".

Alarm bells started ringing and I knew it had to be a scam. But let’s take a look...

There was no reason I could think of why they would use a bit.ly URL unless they didn’t want people to notice right away that it wasn’t a Best Buy site.  This way, people are forced to click through.  (There are good reasons for using bit.ly.  For example, a medium such as Twitter restricts the size of your entry. Or you have a legitimate need to obfuscate the URL.)

The first thing I noticed was:

"AmazingFreeRewards.com is not affiliated with Best Buy®, Inc."

ALL of the links on this page return you to this page, except for the Gift Status link that requires a login, a login that you would create if you followed the process through to that point.  Thus, there is no Privacy Policy nor any other information available.  But if you enter a ZIP code, you will be transported to…

All the links here react similarly as the previous page (see tabs; returns or requires login).  But look at all the information they want.  Those are many data items that qualify as Personally Identifiable Information (PII) for which a Privacy Policy is required because there are legal ramifications for their inadvertent dispersal.  (I hesitate to call them legal protections as all we get is notification.)

But so far, all this probably looks legitimate for an offer such as this, and this is no more than a warning for people to think twice before divulging their PII. You might think it’s worth your PII for a chance at $1000.  But consider how you got here.  There was an Event on Facebook. Friends are giving up their friends' personal data by RSVPing to the offer.  Almost 10,000 people gave this company all their Facebook info about themselves and their friends.  This company has possibly accumulated over one-third of a million email addresses for its future spam campaigns, or perhaps it plans to sell the list to other spammers.  Such a list is worth more than a couple thousand dollars.  Pretty good returns for the creation of a Facebook Event.

But why is this a scam?  Again, we start at the beginning.  “Best Buy Celebrates Its 20 Year Anniversary!”  You can see from the official Best Buy corporate history that they existed prior to 1983 when the company changed its name to Best Buy and were already trading on the Nasdaq in 1985. If anything, they would be celebrating their 25th, 27th, or even 44th anniversaries.

The lesson here, guard your personal information. But also, guard your friends’ personal information.  Don’t go giving it away when you have no idea who is on the other end taking it all in.

-- Jimmy Kuo

PS. I contacted Facebook and the Event page was gone by the next morning.

Last month we had reported good cleaning results against the Win32/Alureon rootkit, and this month we have more good numbers to share with the May edition of MSRT. Similar to last month, we continued to add detection for newer variants of Alureon:

As can be inferred from the numbers, compared to last month, the new .H variant is the most prominent in terms of prevalence. There were several changes to the design of the rootkit to avoid detection and cleaning, revealing that the rootkit is still under active development and distribution. One of the notable changes was to infect arbitrary system drivers instead of only the hooked miniport driver.  Expectedly, this can have negative side effects on the machine depending on the chosen driver.  For example, we’ve seen some machines having their keyboard disabled as a result of an infection. On other machines, Windows XP unexpectedly requests reactivation because the infection appears like a significant hardware change. 

Moreover, the trend percentages also show that some older variants of the rootkit “upgrade” to the latest version relatively quickly after a new release. However, the .A variant is still prevalent because of its use with a different malicious payload, called zooclicker. Overall the number of computer cleaned increased by a whopping 37% compared to April due to a spurt in detection of the newest variant and as a result, Alureon climbed to the number 1 family spot in MSRT May.

Continuing the trend from last month, more than three-quarters of the infections occur on machines running Windows XP. This is likely due to better security in the later versions of the Microsoft Windows operating systems.  The dominance of XP SP3 can be attributed to the combination of the above in conjunction with its high prevalence of use.

The geographical location distribution is consistent with last month’s statistics and still reflects the prevalence bias of the malware in English speaking country.

Moreover, the new family for this month, Win32/Oficla was cleaned from 74,690 machines. In total, MSRT May cleaned malware infections from 1,961,243 machines and below are the top most prevalent threat families cleaned with MSRT in May.

 As always, we strongly urge users to run the latest version and updated signatures of an Anti-Malware product such as our Microsoft Security Essentials in order to stay protected.

- Vishal Kapoor and Joe Johnson