Security and Privacy

• Doing the Zbot spot; playing gotcha with a botnet

  Greetings Internet!

  This month (carefully hidden under the Win32/Bamital blanket), employing the old adage ‘fight fire with fire’, we decided to fight sneakiness with sneakiness and quietly slipped a fairly major Win32/Zbot update into MSRT.
   
  “Zbot” I hear you say? Yes, it’s still around and kicking. Despite Win32/Zbot (officially self-titled with the oh-so-ego-inflating ‘Zeus’ moniker, despite never fathering Hercules bot, nor employing lightning in any way during infection) being rumoured to have merged with Win32/EyeStye (aka SpyEye), we’re still seeing both distinct malware families out and about in the wild. Between the two, we’re finding that they’re responsible for a significant amount of the e-commerce-related fraud happening at any given time.
   
  Of course, since Zbot has been in MSRT since last October, MSRT has been continually updated monthly with all of our related signatures. We believe this tried-and-true method is effective – every month we clean between 60,000 and over 100,000 unique Windows computers:

   

  Month	Count
  March	103391
  April	113814
  May	60385
  June	83555
  July	61323
  August	89994

  So what’s changed? Well, let’s just say we felt it was time to turn the screws tighter on Zbot again. Whilst we get to do some pretty in-depth analysis of infections through the telemetry we get back from Microsoft Security Essentials, it’s time for us to get a really definitive snapshot of the Zbot infection ecosystem as best we could. I know! Statistics are fun! High five!

  Ideally, this information will help us and our partners in law enforcement battle the threat more effectively in the future.

  Naturally, once we see how things pan out in MSRT over the next couple of days, I’ll update you on how it’s all going!

  Until next we meet via the medium of blog (and/or interpretive dance),

   
  Matt McCormack
  MMPC Melbourne

  

Digest powered by RSS Digest

• Bamm Bamm, Rubble.

  The family selected for addition to MSRT this month is Win32/Bamital. Win32/Bamital was first discovered in September 2009 and was able to intercept and modify queries performed by search engines such as AltaVista, Bing, Google and Yahoo. Win32/Bamital has evolved over a number of generations, employing a varying range of system modifications to ensure that the malicious code is executed. Whilst the complexity of Win32/Bamital has increased over time, the core functionality of search hijacking has remained.

   

  For example, here is an extract from a current generation template Win32/Bamital employs to drive this functionality:

   

  

   

  Some of the modifications observed over time include the ability to generate domain names for command and control algorithmically, a technique also employed by other high-profile malware such as Win32/Sinowal and Win32/Conficker for example.

   

  In this case, the Date header in the HTTP response from a simple request to google.com acts as the seed for this process.

   

  Date: Wed, 14 Sep 2011 00:42:36 GMT

   

  An MD5 hash is calculated on a portion of this string, prepending 10 different single characters.

   

      MD5(%character%14 Sep 2011)

   

  This currently provides an upper limit of 40 domain names per day by using four different suffixes.

   

      %hash%.co.cc

      %hash%.cz.cc

      %hash%.info

      %hash%.org

   

  Here are a couple of examples for the small number of IP addresses to which the generated domain names resolve currently.

   

  Name:

      37C716B1EF8A468B4301314DCCE830FA.cz.cc

  Address:

      178.238.36.7    (178-238-36-7.static.masterinter.net)

   

  Name:

      37C716B1EF8A468B4301314DCCE830FA.co.cc

  Addresses:

      46.137.253.137  (ec2-46-137-253-137.ap-southeast-1.compute.amazonaws.com)

      46.137.253.141  (ec2-46-137-253-141.ap-southeast-1.compute.amazonaws.com)

      46.137.253.144  (ec2-46-137-253-144.ap-southeast-1.compute.amazonaws.com)

   

   

  Interestingly, we can see that the authors of Win32/Bamital are employing the use of Amazon Web Services as part of their command and control infrastructure. We notified Amazon of the abuse and received confirmation that it is being investigated.

   

  – Scott Molenkamp 

  

Digest powered by RSS Digest

• Win32/AdsLock – advertising content locking tool turned ransomware

  It is clear that breaking search engine rules and exploiting functionality to drive traffic and monetize content is a lucrative and extremely viable business for unethical or so called “blackhat” search engine optimization (SEO). We have recently seen another method of driving traffic and monetizing content that doesn’t involve directly serving malicious content via search engine results, but rather uses a modified version of an Internet advertising technique known as content locking.

  According to information released in May by the Interactive Advertising Bureau (IAB), “Internet advertising revenues in the U.S. hit $7.3 billion for the first quarter of 2011, representing a 23 percent increase over the same period in 2010“. The full IAB 2010 report contains more detailed information, suggesting that the most popular ad format for 2010, which represented 46% of $26 billion in revenue, came from search.

  Content locking is an ad content delivery model that forces visitors to complete an action before they can access desired content. This model can be monetized with cost-per-action (CPA) offers that provide visitors with some form of incentive, such as a service or free content, for performing the required action. Most affiliate websites enable this feature by using content locking software or tools, which basically lock the content, and then communicate to an ad-content gateway in order to capture CPA offers.

  Trojan:Win32/AdsLock.A is a newly discovered threat that was found exploiting this model, but instead of locking web content, it is designed to lock the affected user’s computer screen. It communicates with a malicious content gateway, which serves unwanted and controversial or illegal images to the affected user. It then displays the following threatening message, implying that the user has been engaged in an illegal activity:

  

  Constructor:Win32/AdsLock.A is a detection for a malicious tool that generates Trojan:Win32/AdsLock.A, which we have observed being distributed and promoted as an SEO tool. The constructor includes limited features, and seems to be in the early stages of development. However, it’s worth noting that the idea presents an opportunity to maximize monetization from infections.

  - Methusela Cebrian Ferrer

  

• More on Morto

  As some of you might be aware, we’ve recently been seeing low levels of reports of Win32/Morto – a worm that causes headaches for users who may have less than ideal password policies – so we thought we’d look at this in more detail.

  The number of computers reporting infections or infection attempts continues to remain quite low. In total, the MMPC has seen only a few thousand unique computers report this issue.  For an idea of how this kind of volume compares to other families, see the following chart that shows the volume of several families (Sality, IRCbot, and Morto) by unique computers last Sat. (Aug. 27, 2011).

   

  

   

  This threat is reaching both consumer and corporate users alike in 87 country/regions so far.  At first, the majority of telemetry we received was from computers on older platforms, mostly Windows XP.  More recent telemetry shows that newer platforms are also seeing this worm:

   

  

   

  We’ve also discovered that Morto attempts to compromise more than just the ‘Administrator’ account when trying to brute force RDP connections with its simple dictionary attack. Initially it tests the affected machine’s Internet connectivity by attempting to connect to IP 74.125.71.104 (this is an IP owned by a legitimate corporation and is otherwise unrelated to the malware). If this attempt is not successful, it then cycles through IP addresses on the affected computer’s subnet and attempts to connect to targeted hosts using the following usernames:

  1
  actuser
  adm
  admin
  admin2
  administrator
  aspnet
  backup
  computer
  console
  david
  guest
  john
  owner
  root
  server
  sql
  support
  support_388945a0
  sys
  test2
  test3
  user
  user1
  user5 

  It’s important to remember that this malware does not exploit a vulnerability in Remote Desktop Protocol, but instead relies on weak passwords (you can see the passwords used by Morto in our encyclopedia). If you haven’t already, check if these usernames are being used in your environment and change the associated passwords to ones that are strong (and definitely not on the password list).  Even computers that have been cleaned of this threat can be easily reinfected if the passwords are not changed and the computer remains unprotected.

  The role that passwords play in securing an organization’s network is often underestimated and overlooked. Passwords provide a first line of defense against unauthorized access to your organization.

  We encourage people to use strong passwords to help protect their systems. (You can even test the strength of your proposed password using our password checker.) We also encourage enterprise users in particular to enforce both strong passwords and regular password changes via policy.

  Holly Stewart and Matt McCormack
  MMPC Melbourne and Redmond

  

• New worm targeting weak passwords on Remote Desktop connections (port 3389)

  We’ve had reports of a new worm in the wild and that generates increased RDP traffic for our users on port 3389. Although the overall numbers of computers reporting detections are low in comparison to more established malware families, the traffic it generates is noticeable. The worm is detected as Worm:Win32/Morto.A and you can see a detailed description of it at Worm:Win32/Morto.A.

  Morto attempts to compromise Remote Desktop connections in order to penetrate remote systems, by exploiting weak administrator passwords. Once a new system is compromised, it connects to a remote server in order to download additional information and update its components. It also terminates processes for locally running security applications in order to ensure its activity continues uninterrupted. Affected users should note that a reboot may be required in order to complete the cleaning process.
   
  This particular worm highlights the importance of setting strong system passwords. Using strong passwords can go a long way towards protecting your environment — and  the ability of attackers to exploit weak passwords shouldn’t be underestimated. For example, Morto tries the following passwords:
   
  *1234
  0
  111
  123
  369
  1111
  12345
  111111
  123123
  123321
  123456
  168168
  520520
  654321
  666666
  888888
  1234567
  12345678
  123456789
  1234567890
  %u%
  %u%12
  1234qwer
  1q2w3e
  1qaz2wsx
  aaa
  abc123
  abcd1234
  admin
  admin123
  letmein
  pass
  password
  server
  test
  user
   
  When creating strong passwords, remember that the key to a strong password is length and complexity. Here’s a few tips to keep in mind:

  • An ideal password is long and has letters, punctuation, symbols, and numbers.
  • Whenever possible, use at least 14 characters or more.
  • The greater the variety of characters in your password, the better.
  • Use the entire keyboard, not just the letters and characters you use or see most often.

  For more advice on creating (and remembering) strong passwords, visit our Safety and Security Center. 
   
  For your information here are some examples of files that are being detected as Win32/Morto:
  0x48AE936692FFBD14782D5C97DD067402FBB52356
  0x6929EAD324EFA7A667BAE88A041F546DBBECBF26
  0x188BA0E3A03BFFFF4B9C96721AC70EF68D19A86E
   
  Hil Gradascevic
  MMPC Melbourne

  

• Keeping malware away – how do some countries do it?

  Our friend Tim Rains over at Trustworthy Computing (TwC) has just concluded a six-part series in which he took a closer look at the threat landscape in locations that have the lowest infection rates in the world. Using data from our Security Intelligence Report, the series investigates why the same countries and regions consistently pop up as having relatively low malware infection rates, as normalized using a metric called Computers Cleaned per Mille (CCM).

  The series is available in the following articles:

  • Lessons from Some of the Least Malware Infected Countries in the World – Part 1
  • Austria – Lessons from Some of the Least Malware Infected Countries in the World – Part 2
  • Finland – Lessons from Some of the Least Malware Infected Countries in the World – Part 3
  • Germany – Lessons from Some of the Least Malware Infected Countries in the World – Part 4
  • Japan – Lessons from Some of the Least Malware Infected Countries in the World – Part 5
  • Finale – Lessons from Some of the Least Malware Infected Countries in the World – Part 6

  What was commonly found in these locations that have low malware infection rates includes the following:

  1. A strong relationship between public and private entities that led to efficient and proactive responses to malware threats
  2. The presence of CERTs, ISPs, and other entities that monitor malware that enable rapid response
  3. An intelligent and well-trained IT culture where system administrators are able to sufficiently respond to threats
  4. The establishment of policies and processes to quarantine infected computers and prevent malware from spreading across networks
  5. Education campaigns and media participation that raise awareness of security issues
  6. Low software piracy rates and timely and widespread use of Windows Update and Microsoft Update

  A big thank you to Tim and the TwC, who collated all this information to help us understand what certain countries and regions are doing right regarding keeping malware away. We strongly encourage users to employ the best practices found in the countries that have these low malware infection rates.

  - MMPC

  

• Can we believe our eyes?

  Several days ago, one of our customers submitted a sample (SHA1: fbe71968d4c5399c2906b56d9feadf19a35beb97, detected as TrojanDropper:Win32/Vundo.L). This trojan hijacks  the hosts “vk.com” and “vkontakte.ru” (both social networking sites in Russia)and redirects them to 92.38.209.252, but achieves this in an unusual way.

  A common  method used to hijack a website and redirect it to a site of the attacker’s choice is to add an entry in the Windows hosts file located in the %SystemRoot%\system32\drivers\etc directory. However, when we open this file on an affected computer, it doesn’t contain any entries related to “vk.com” and “vkontakte.ru”, as you can see in the following example:

   

  But when we show hidden files, we can see another “hosts” file. It is hidden, as in the following example:

   

  There are two files with exactly the same name, “hosts”, in the etc directory! How can this happen?

  As we know, it is not possible for a directory to contain two files with the same name. When we copy the file names to notepad, save them as a Unicode text file and open them with a hex editor we see the following (the upper is for the first “hosts” file, the lower is for the second “hosts” file):

  

  For Unicode (UTF-16), the 0x006F is the same as 0x6F in ASCII, which is the character “o”. But what’s the 0x043E in Unicode? We can find it in Unicode chart table (Range: 0400-04FF). The following is part of this table.

   

  We can see that Unicode 0x043E is a Cyrillic character, and it looks very much like the English character “o”.
  So the hidden “hosts” file is the real hosts file in fact. When we open this file, we can see that two entries have been added to the end of the file:

   

  Mystery solved!

  This is not the first time we’ve seen a hacker using Unicode characters to mislead people. In Aug 2010, a Chinese hacker disclosed a trick with a Unicode control character used to mislead people into running an executable file. Hackers use Unicode control characters 0x202E (RLO) to reverse parts of a special file name, which changes the look of the file name in Windows Explorer.

  For example, there is a file named as “picgpj.exe”, as the following:

  

  The “gpj.exe” part of this name is specially crafted. When inserting an RLO character before “gpj.exe” in this name, the whole name appears as the following:

  

  Hackers also usually use a picture as the file icon. Unwary people treat this file as a picture, and blindly double-click to open it, thus running the executable. Obviously, this type of trick is useless for Unicode aware programs, but it is not easy for the eyes of people to identify the problem.

  Can we believe our eyes? The answer is… not always.

  Zhitao Zhou

  

• MSRT August ’11: FakeSysdef

  This month’s Malicious Software Removal Tool (MSRT) includes Win32/FakeSysdef – one of the most prevalent trojans affecting our support groups over the past few months. We’ve discussed this threat in previous blogs (1, 2), and turn to this excerpt from our encyclopedia for some more detail:

  Win32/FakeSysdef is a family of programs that claim to scan for hardware defects related to system memory, hard drives and over-all system performance. They scan the system, show fake hardware problems, and offer a solution to defrag hard drives and optimize system performance. They then inform the user that they need to pay money to download a ‘fix’ module, register the software and repair these non-existent hardware problems.”

  The first variant we saw in the wild called itself “System Defragmenter” hence the name, FakeSysdef (SHA1: C5130D12851D03ED42A7CC25BE5629E0A43E90A2).

  With a trained eye, we found some tell-tale signs that the authors behind Win32/FakeCog are related to those behind Win32/FakeSysdef. It also seems coincidental that FakeSysdef’s first release was a month after the inclusion of Win32/FakeCog to MSRT last September. Since that time, FakeCog detections have decreased while FakeSysdef detections have become more prevalent.

  How do I get infected?
  Creators of trojan and rogue security software are notorious for using exploit kits and “search result poisoning”, or Black SEO, to launch installers of their malware. For example, malware creators could use an image search poisoning scheme to deliver poisoned search results to users that search for a photo of a popular or public person. When opening a (malicious) returned search results page, the user could become infected by way of a drive-by download that executes a Win32/FakeSysdef installer. FakeSysdef may also be downloaded by other malware, including Win32/Chepvil.

  Win32/FakeSysdef drops a copy of itself and/or another component (DLL or EXE) to the “%APPDATA%” folder using random filenames, for instance:

  • c:\Documents and Settings\All Users\Application Data\<RANDOM>.exe
  • c:\Documents and Settings\<UserName>\Local Settings\Application Data\<RANDOM>.exe

  Note: These folders are commonly hidden, so you might need to check these links for Windows Vista and Windows 7 to enable the viewing of hidden files and folders to see the dropped files.

  Here is an example of the dropped files (the main executable and a configuration data file):

  
  Figure 1 – Dropped files

  A shortcut link is created in the desktop folder and sometimes in the Program menu, hoping that the user will run it eventually. Others may just create a plain autorun registry entry to run the trojan every time Windows starts.

  To be more appealing, recent FakeSysdef variants are smart enough to detect the operating system when constructing the brand names they use. An example of this strain is the “Windows 7 Recovery”distribution that checks the Windows version with common APIs such as GetVersionExW() and GetNativeSystemInfo(). Other variants with similar behavior are: “Windows 7 Restore” and “Windows 7 Repair”.

  
  Figure 2 – View of API call by FakeSysdef

  Win32/FakeSysdef typical behavior, once active, is to display fake error messages such as those seen in Figure 3, that scare the user into believing that their computer needs repair. But before they can clean up their computer, they need to buy or register the software. Needless to say, this is the old-and-dirty trick from rogues and some trojans to scam money from infected users – to scare you into buying their fake software. If the user ignores the malware (eg. clicking ‘Cancel’), it reboots the machine repeatedly until they activate the fake fix. Downloading and installing the fake fix module will not clean up the computer and it doubles the risk by downloading an additional component or different new malware.

  
  Figure 3 – Examples of fake error messages from FakeSysdef

  
  Figure 4 – FakeSysdef fake request to “Fix problem”

  After installation, it connects to a remote website to report infection information. The remote website’s URI formats are all the same or similar and hard-coded in the binary with simple encryption. The %s format in the decrypted string (Figure 5) is replaced later in the code by the actual hardcoded domain name. This means that the binary is being auto-generated with some kind of server-side polymorphic engine, embedding the URI of the C&C domain on every binary compiled. The domains used also look pre-generated, being registered when the binary is released.

  

  Figure 5 – Analysis of FakeSysdef illustrates call to decrypt URI string

  Blocking programs
  Perhaps, it’s worth noting as well that a small fraction of FakeSysdef variants were found to be blocking launched programs once active. It accomplishes this by using a DLL component injected to some pre-determined processes like EXPLORER.EXE, WINLOGON.EXE and WININET.EXE with the following registry entry:

  In subkey: HKLM\System\CurrentControlSet\Control\Session Manager\AppCertDlls
  Sets value: “AppSecDll”
  With Data: “c:\documents and settings\all users\application data\<RANDOM>.dll“

  The DLL exports the CreateProcessNotify() function to check if the trojan is installed by querying some registry entries related to itself and denying programs that are executed by the user. This aggravates its effect especially for cleanup, as you cannot run programs to remove the trojan. Users might need to boot from Safe Mode to clean this strain.

  Ties with other malware
  The underground business of malware has a complex structure and different malware families are often inter-related. For example, we have observed Win32/Hiloti installing Win32/FakeSysdef in the past. FakeSysdef in return, was also found to download and install Win32/Alureon.

  With the inclusion of FakeSysdef in this month’s MSRT, we hope that its extinction is imminent!

  – Rex, MMPC

  

• A Bit of Archaeology

  This entry has nothing to do with malware. Just so you know.

  Some people know that I like the demo scene. I’ve been following it for more than 20 years now, but it’s even older than that. I like the size-optimisation competitions best, and I’ve even participated in a few – most recently, smallest downloader on 32-bit Windows XP: 233 bytes (255 bytes on Vista and later), print the EICAR test string: 56 bytes. Of particular interest to me are the demos in 512 bytes or less. They are so small that in order to have cool effects, a structured file is unusable, so only a .com file works here. As a result, they only run in DOS or a 32-bit console window (or via an emulator). No 64-bit systems here. Even now, in 2011, there was a 128-bytes competition, and the year is not over yet.

  How do you make a file that small? Mostly it’s just amazing code, but to save a few bytes it’s also quite common to rely on the initial register values instead of initialising them manually.

  The question, though, is which registers hold what values… and why? This is something that I have never seen written down. I suspect that it’s just something that “everybody knows”.

  Let’s take a look at a few versions of DOS, to see what I mean:

  version
  reg 3.3 4.01 5.0 6.0 7.0
  ax 0000 0000 0000 0000 0000
  cx 00ff 00ff 00ff 00ff 00ff
  dx cs cs cs cs cs
  bx 0000 0000 0000 0000 0000
  bp 0882 091c 091c 091c 091c
  si ip ip ip ip 0100
  di sp sp sp sp sp

  Note that these values are for real DOS. For certain versions of the Windows console, the bp register value is 091e.

  So that’s the which and the what. As for the why…

  bp:
  0019:000041DA BC 20 09 MOV SP, 0920
  …
  0019:000041F9 36 FF 16 EA 05 CALL NEAR WORD PTR SS:[05EA]

  Now the sp register value is 091e.

  0019:00009B6E 55 PUSH BP

  Now the sp register value is 091c.

  0019:00009B6F 8B EC MOV BP, SP

  And now so is the bp register value.

  dx:
  0019:00009FA6 8B 56 EE MOV DX, WORD PTR SS:[BP - 12]

  This value is the result of a memory allocation, and depends on the size and structure of the image being loaded.

  cx:
  0019:0000A02F F3 A4 REPE MOVS BYTE PTR ES:[DI], BYTE PTR DS:[SI]

  Now the cx register value is 0000.

  0019:0000A031 FE C9 DEC CL

  And now it’s 00ff.

  bx:
  0019:0000A035 32 FF XOR BH, BH
  …
  0019:0000A040 32 DB XOR BL, BL

  Now the bx register value is 0000.

  si:
  0019:0000A0AC 36 C5 36 C4 0F LDS SI, DWORD PTR SS:[0FC4]

  Now the si register value is assigned, and depends on the structure of the image being loaded (0100 for .com files).

  di:
  0019:0000A0B1 36 C4 3E C0 0F LES DI, DWORD PTR SS:[0FC0]

  Now the di register value is assigned, and depends on the structure of the image being loaded (fffe for .com files).

  ss:
  0019:0000A0B6 8C C0 MOV AX, ES
  …
  0019:0000A0E1 8E D0 MOV SS, AX

  Here we see that the dx register is not the source of the ss register value, as is commonly assumed.

  sp:
  0019:0000A0E3 8B E7 MOV SP, DI

  Now the sp register is assigned, and we see that the di register is its source.

  0019:0000A0E6 1E PUSH DS
  0019:0000A0E7 56 PUSH SI

  Aliases for the cs and ip registers are pushed onto the stack, and we see that the dx register is not the source of the cs register value, either.

  ds, es:
  0019:0000A0E8 8E C2 MOV ES, DX
  0019:0000A0EA 8E DA MOV DS, DX

  ax:
  0019:0000A0EC 8B C3 MOV AX, BX

  Now the ax register value is 0000.

  0019:0000A0EE CB RETFW

  The file runs, and the mystery is solved.

  - Peter Ferrie

  

• UAC plays defense against Malware

  User Account Control (UAC) was probably the first new feature of Windows Vista that most users encountered, and received considerable attention when the OS was released. UAC gives a way for users to act as computer administrators just for administrator tasks. This is important to only allow software that requires elevated rights to run with such powerful (and potentially dangerous) rights. Over time, UAC prompts have diminished, especially with the release of Windows 7. But it’s clear malware authors really hate UAC.

  When UAC was introduced, the verdict from malware authors was remarkably clear – go around it. This was a total change from Windows XP, and advice on malware forums was nearly universal. Instead of running malware as an administrator from locations easily accessible with administrator rights, just start running in the user profile with user rights. This was unfortunately not a big problem for malware. However it did become very difficult for malware to elevate to administrator rights, which was the purpose of UAC, most malware have decided to simply go around it.

  While UAC avoidance continues as a tactic, the Microsoft Malware Protection Center has found more and more malware opening a new front and turning UAC off itself. Malware does this to prevent users from seeing UAC prompts on every reboot for their payloads. The Sality virus family, Alureon rootkits, Rogue antivirus like FakePAV, Autorun worms, and the Bancos banking Trojans all have variants turning UAC off. So many are doing this that Microsoft Security Essentials, Windows Intune, and Forefront Endpoint Protection now uses behavior monitoring to find software that manipulates UAC settings, and the MMPC is finding brand new malware disabling UAC regularly.

  The key factor here is that for malware to successfully turn UAC off, the malware must itself be elevated to run as administrator. This elevation either requires an exploit in a service with administrator access, UAC to already be turned off, or a user clicking “OK” on a UAC prompt to allow the malware to elevate. Unfortunately, many Windows users have disabled UAC. While malware was mostly avoiding UAC altogether, legitimate software was also being rewritten to not require elevation prompts, so there are fewer UAC prompts than ever to wrangle, which should make it easier to spot any suspicious activity.

  In the below chart of the top 5 threats from machines with UAC off from a single day, we see both techniques. The Rorpian worm may exploit the Domain Name System (DNS) Server Service vulnerability, which allows it to gain Administrator rights and turn UAC off. SideTab and OneScan, however, use social engineering techniques to get elevated and then disable UAC.

  Threat	UAC Disabled
  Worm:Win32/Rorpian.gen!A	95%
  Worm:Win32/Rorpian.E!lnk	92%
  Worm:Win32/Rorpian.E!inf	92%
  Adware:Win32/SideTab	82%
  Rogue:Win32/Onescan	68%

  About 23% of computers reporting detections in a day had UAC disabled. While some threats directly turn off UAC, others have a lower success rate when UAC is on.

  In addition to always updating your software and running up to date antivirus, the best thing to do is to leave UAC enabled. UAC is not intended as malware protection, but it’s another layer of security to help improve the safety of Windows. If you’ve been attacked from malware, please check the UAC setting in the control panel to see if it’s been tampered. It’s easy to do through the control panel by following these instructions: Turn UAC on, and prompts should now be rare. If a UAC prompt you don’t expect pops up, you can also click on “no”, too.

  Joe Faulhaber

  

• MMPC Portal available in 35 languages

  ?We’d like to announce the launch of the automatic translations feature on the MMPC Portal.

  Take a look at http://www.microsoft.com/security/portal/, scroll down to the bottom of the page, and translate to the language of your choice.

  These translations are completely automatic, and are using Microsoft Bing technology. This technology is considered state of the art in machine translation, and the quality is undergoing constant improvements. When applying the translation, the original text can be viewed by hovering over a particular phrase or sentence. 35 languages are currently supported on the MMPC Portal site.

  We’re excited to have this opportunity to expose the portal content to our broad base of international users!

  - Ronit Reger

  

Digest powered by RSS Digest