Recently we have seen an increase in fake Microsoft scams, which function by tricking people into thinking that their PC is infected. With these types of scams there are a number of things to remember.
1. Microsoft will never call you telling you that your PC is infected 2. Never allow strangers to connect to your PC 3. Do not give any credit card info to somebody claiming to be from Microsoft 4. If in doubt, shut down your PC and call Webroot
The current scam will display a webpage that is very similar to the one in Figure 1. There are a number of ways to figure out that this is a false alert. The first is that it’s a website message and not a program; the second is that location of the web site will be a random string of letters.
If there is one thing that can be observed about the AV industry, it is that no solution is ever 100% effective at blocking malware. With this in mind, Webroot SecureAnywhere (WSA) was designed to protect users even in cases where undetected malicious software has made it onto the system.
AV-Comparatives recently published results for June’s “Real World” Protection Test. This test aims to replicate a real world experience for how malware would infect a PC. The scores indicate how many threats were detected vs. missed.
I’ve worked in the security industry for nearly five years, and it was apparent early on that the most successful people in this field bring to their work a passion and a commitment to protecting not only one’s customers, but to providing a certain level of information about security threats to the world at-large, so even your non-customers can help or protect themselves.
It can be hard to know where to stop once you get on a roll. Malware infections frequently lead to unexplored, interesting backwaters on the Internet. And, sometimes, those backwaters are where the criminals run those operations. When I stumble upon a criminal network or a botnet controller, it simply doesn’t feel like I’ve done enough when I merely add signatures which block or remediate infections and communications with a command-and-control server from Webroot customers. If malicious behavior depends on one or more Internet sites that send instructions, my (and many others’) initial reaction is we need to shut that down, permanently. But sometimes, a too-rapid reaction can blow back in your face.
Obviously, that was also the case when Alex Lanstein and Julia Wolf of internet security firm FireEye stumbled upon the Rustock botnet. At one time, before law enforcement in several countries swooped in on the data centers hosting the botnet’s command-and-control (CnC) infrastructure in a coordinated raid earlier this year, the massive network of Rustock-infected computers was responsible for about half of spam flooding the ‘net. The researchers’ instincts to engineer a takedown of the botnet sounded very familiar, but their initial attempts to do so backfired, and may have even spurred the malware developers to change their game, and may have made it more difficult, eventually, to eliminate the CnC altogether.
There are fewer types of malware infections more frustrating and annoying than a rootkit with backdoor capabilities. Over the past couple of years, we’ve seen the emergence of this new, tough-to-fight infectious code, and its transformation from nuisance to severe threat.
With the hard work and perseverance of Threat Research Analyst and master reverse-engineer Marco Giuliani, we’re proud to release the latest build of a tool we’ve used internally to clean the infections from the notable ZeroAccess rootkit off of victims’ computers. AntiZeroAccess exploits many of the vulnerabilities that Marco discovered in the rootkit to cleanly remove the rootkit code from infected machines.
The free tool removes the rootkit but does not restore the Access Control Lists (ACLs) that have been modified by the rootkit. For that, you’ll probably want to use a free tool like SetACL, which can make software functional that ZeroAccess disabled by modifying its ACL.
The criminals who push rogues at the world don’t really care about the reputations of the ISPs or Web hosting services they abuse. They leap from free service to free service until they’ve thoroughly worn out their welcome and, in some cases, destroyed the reputation of the service they abused. But they have behaved in one predictable way over the years: They’re stingy, and won’t pay for anything unless it’s absolutely necessary, despite the fact that they’re raking in cash by the boatload.
But that seemed to change this week when we saw a number of Web sites pop up on the radar. The sites employ the now well-worn scam of pretending to be some sort of video streaming service. In this case, they pretended to be a porn site, but the most surprising part was not what was hosted, but where: Amazon’s Cloudfront hosting service ended up, temporarily for a few hours, serving up malicious Web pages. Amazingly, it seems they actually paid for hosting instead of just stealing it.
Amazon shut the sites down quickly, but before they did, we visited one site called xrvid-porno.com. The page isn’t exactly family friendly, but the gist of the scam is that that page eventually redirected the browser to a server inside of Amazon’s cloud hosting service, and that’s where the trouble began.
Among the most infamous kernel mode rootkits in the wild, most of them have had a slowdown in their development cycle – TDL rootkit, MBR rootkit, Rustock are just some examples. The same doesn’t apply for the ZeroAccess rootkit. The team behind it is working quite hard, which we know for a fact because I’ve seen it.
We already talked about this rootkit and its evolutions in several blog posts, along with a white paper that documents more in depth all the technical features of the malware. The last major update released by the team behind ZeroAccess dates back a couple of weeks; That update implemented a strong self-defense routine able to kill security software programs that try to get access to its code, blocking the security software from running by manipulating access control list, or ACL, settings.
Last week ZeroAccess received another update, and again it’s a major one. The rootkit shifted from a hidden encrypted file used as an NTFS filesystem volume to a more comfortable hidden directory created inside the Windows folder, where the rootkit still stores its configuration data and other malware in an encrypted form. Continue reading →
Last week, threat researcher and malware reverse-engineer Marco Giuliani wrote up a fairly technical description of a bootkit — a rootkit that infects the master boot record of the hard drive, making it very difficult to remove — called Popureb. Marco’s report made it clear that the bootkit does not require Windows users to format the hard drive and reinstall Windows from scratch, as Microsoft had initially claimed was required for victims of this drive-by infection.
Andrea Allevi, one of our developers who works under Marco’s direction, subsequently wrote a tool that can remove the bootkit from an infected computer, which we’re releasing today to the public. We don’t offer technical support for the tool, but it’s fairly straightforward to use: Just launch it on a system infected with Popureb.E, using an account with Administrator privileges. It will ask your permission to clean the infected MBR, and once you say ‘yes’ it’ll do the rest. You’re welcome!
Last Wednesday, Microsoft published a blog post detailing a significant update to a piece of malware named Popureb. The malware adds code to the Master Boot Record, or MBR, a region of the hard disk that’s read by the PC during bootup, long before the operating system has had a chance to get started. Researchers sometimes refer to these kinds of malware as bootkits, or a rootkit which loads at such a low level during the boot process that it is invisible to the operating system, and therefore very difficult to remove.
Microsoft researcher Chun Feng detailed some of the new features of Popureb.E, which includes a very low-level hook into the Windows driver responsible for disk writes and reads. When the driver on an infected system detects an attempt to write changes into the MBR — the kinds of changes a repair tool might try to make — it simply changes the command from write to read, effectively neutering any kind of tool running within Windows that might try to fix the infection.
Microsoft’s initial cleanup guidance on Popureb.E was pretty drastic, and more than a little scary: Full removal of the bootkit requires a full reinstall of Windows, wiping out anything currently on the hard drive. We don’t think this is the case, and the Microsoft folks seem to have moderated their advice to include some manual fixes using the recovery console.
While the whole concept behind the Trojan is valid and technically powerful, the practical implementation of the malware is not as valid as the idea behind it. What follows is a fairly technical write-up that describes both the problem, and one solution we’ve come up with.
This week, we turn our attention temporarily away from the never-ending stream of rogue security products on the Windows platform and take a closer look at the Mac OS analogue, MacProtector (aka Mac Security, Mac Defender, MacGuard, and–if history serves–soon to be many, many other names).
There’s been a lot of press coverage of these rogues — including a video blog post by us — in the past few weeks, so we thought it was high time we took a deeper dive.
Even though Webroot doesn’t offer an automated removal solution for the Mac, there’s good news for most Mac users — with only a little bit of effort, it’s fairly rudimentary to simply delete the rogue .app and be done with it. In this case, the Activity Monitor (Apple’s GUI process monitor, located by default in the Utilities folder inside the Applications folder) is your best friend.
The program appears as a stub .mpkg installer, which means that the application that installs the program isn’t a container with the full program stuffed inside. The installer drops an app named avRunner.app into the Applications directory, then executes it.