We have just completed fresh analysis of the malicious software known as Win32/Festi. While the “Festi” botnet created with this malware has been in business since the autumn of 2009 we can see that the software is frequently updated, as described in our analysis, and these updates mean Festi continues to be a potent threat (Festi is detected by ESET as Win32/Rootki.Festi). You can download our whitepaper with the complete analysis here (.pdf). What follows are some of the highlights.

According to statistics from M86 Security Labs, Win32/Festi is one of the three most active spam botnets in the world. Thanks to plugin modules that we describe in our analysis Win32/Festi is also capable of being used for distributed denial of service (DDoS) attacks. The malware's kernel-mode driver implements backdoor functionality and is capable of:

1. Updating configuration data from the C&C (command and control server);
2. Downloading additional dedicated plugins.

As show in the diagram on the right, the Win32/Festi kernel-mode driver periodically contacts the C&C server and requests plugins and configuration information. The downloaded plugins perform the bot’s main tasks, such as sending spam.

In an interesting twist, these plugins are kernel-mode drivers which aren’t saved on any storage device in the system and are volatile in memory. Thus, when the infected computer is switched off or rebooted, which a victim might do if they sense something is wrong with their system, the plugins vanish from system memory. This makes forensic analysis of the malware significantly harder since the only file stored on the hard drive is the main kernel-mode driver, and this contains neither the payload nor information regarding which sites to attack or target with spam.

Each plugin is dedicated to performing certain kinds of work such as performing DDoS attacks against a specified network resource or sending spam. The plugins communicate with the main driver through a well-defined interface which we have documented in our white paper.

Another interesting aspect of Win32/Festi that we describe in our analysis is the malware's ability to bypass personal firewalls and HIPS systems that may be installed on the infected machine. To communicate with C&C servers and send spam and perform DDoS attacks, Win32/Festi relies on a TCP/IP stack implemented in Microsoft Windows OS in kernel-mode. However, the bot uses a custom implementation of the ZwCreateFile system service to send IRP requests directly to the transport driver.

Other evasive techniques that Win32/Festi employs include detecting whether it is running inside a VMware virtual machine and checking for the presence of a kernel debugger. We describe these in our detailed Win32/Festi analysis (.pdf).

Eugene Rodionov, Malware Researcher
Aleksandr Matrosov, Security Intelligence Team Lead

See the rest here:
King of Spam: Festi botnet analysis

Since last week, we have seen many specially crafted files exploiting CVE-2012-0158, a vulnerability in MSCOMCTL.OCX in Microsoft Office and some other Microsoft products. This exploit can be implemented in a variety of file formats, including RTF, Word, and Excel files. We have already found crafted RTF and Word files in the wild. In the malicious RTF, a vulnerable OLE file is embedded with object and objocx tags.

The following image shows an example of a crafted RTF file containing a vulnerable OLE file. You can see the signature of the OLE file in D0CF11E0. …

Malicious RTF file

Upon opening a crafted file with the vulnerable application, as in other document exploit files, we see an innocent file posing as bait, while in the background, the Trojan files are installed. Here are typical malware installation steps triggered by the vulnerable application, Word in this example:

1. The crafted document is opened by a Word process.

2. Exploiting the vulnerability triggers the shellcode in the OLE file.

3. The shellcode installs the Trojan(s) on the victim’s machine. Typically, the Trojan is installed in the following path:

%userProfile%Local SettingsTemp(filename).exe

4. The shellcode start a new process of Word and opens as bait an innocent document file embedded in the document. Typically the bait file is dropped at:

%userProfile%Local SettingsTemp(filename).doc

5. The shellcode terminates the Word process that opened the crafted document.

Because of steps 4 and 5, users will see Word quit and then immediately relaunch with the bait file. If you see this symptom, check with your system administrator.

These crafted documents typically arrive as email attachments. Users should always exercise caution when opening unsolicited emails. We also strongly recommend installing the latest fix, from April’s Patch Tuesday. (Refer to the Microsoft Bulletin for more information: http://technet.microsoft.com/en-us/security/bulletin/ms12-027)

McAfee detects these malicious document files as:

• Exploit-CVE2012-0158: Detection for MS Office files such as MS Word and MS Excel
• Exploit-CVE2012-0158!rtf : RTF files containing vulnerable OLE containers

Read more:
CVE-2012-0158 Exploit in the Wild

Phishers always try to find new ways to bypass security features and trick ‘educated’ users. Over the years we have seen simplistic phishing attempts where the required information had to be typed into the e-mail body. This worked at that time because phishing was new and hardly anyone had a notion of the implications. Later, when spam filters became aware of these kinds of mails, we saw the evolution to direct links in e-mail, then to obfuscated links in e-mail where the e-mails looked professional and had the appearance of official messages from the organization the phishers desire your information from.

One thing stayed the same and that is the language used in the phishing mails. Most often they are not correct in either a contextual way or grammar-wise. Regardless, all these attempts sooner or later will be blocked by spam filters or by the anti-malware products, or by URL reputation schemes such as Google’s Safe Browsing or Microsoft’s Smart Screen. But, too often, some people still fall victim for these phishers. One observation as to why this happens will be described later in this blog.

In the last few weeks, a new approach can be added to the portfolio of phishing attempts. The e-mail is accompanied by an attachment with the extension “htm” or “html”.

Now why would the phishers use an attachment with html-code rather than a link? There are several reasons for this. Amongst others:

1. Executing the html-code locally will not have your browser go to a website and thus the URL reputation filter will not be applied.
2. Executing the html-code locally for the browser means it is loaded from an intranet rather than from the Internet. Settings are usually less strict for files started/loaded from an intranet.

Some applications have a protection mechanism in place when specific files are executed or loaded directly as an attachment as, for example, Microsoft Office 2010, which will only load the file in a Protected View where active content is disabled

If we look at this specific phishing attempt, besides the fact that the window is not really a properly delineated window with a border, the grammar is far from perfect.

Darkmegi was in the news a couple of months back; it was the first known threat to be delivered through the Microsoft vulnerability CVE-2012-0003 (MIDI Remote Code Execution Vulnerability) exploitation. More recently Darkmegi has been seen in CVE-2011-3544 (Java Runtime Remote Code Execution) drive-by attacks as part of the Gong Da Pack exploit kit. Darkmegi uses a kernel rootkit component to maintain a stronghold on infected systems.

Hook Installation

It’s common for rootkits to deny read and/or delete access to its files and/or registry keys, and Darkmegi is no exception.  The Trojan drops its kernel driver to com32.sys in the Drivers directory. This rootkit drops a usermode component, com32.dll, which gets injected into explorer.exe and iexplore.exe. It also hooks the Dispatch table of ntfs.sys [IRP_MJ_CLOSE, IRP_MJ_CREATE, IRP_MJ_DEVICE_CONTROL] and fastfat.sys to prevent applications from reading (or scanning) the com32.dll and com32.sys files.

Hook Impact

Once the rootkit has compromised the operating system, attempts to copy or read protected files are rejected.

Attempting to copy rootkit driver to another directory.

As a part of the April’s “Patch Tuesday”, Microsoft released a fix for the MS12-024 / CVE-2012-0151 vulnerability.

This issue was discovered and researched by us; we have been in contact with Microsoft engineers for the past few months to fix this problem. The aim of this blog post is to explain the problem, the risks, and possible consequences of the fix.

The title of CVE-2012-0151 is “WinVerifyTrust Signature Validation Vulnerability”. Now, what is this special “WinVerifyTrust” thing? It is a part of the operating system which is responsible for the verification of digital signatures. So, when somebody – be it the operating system itself, an application wanting to check its integrity, or the user manually checking a file’s integrity from the Properties tab – wants to validate a file, this is the piece of code that gets called to process the digital signature. The processing consists of two steps; the first step is to make sure that the file hasn’t been tampered with. The code applies complex mathematical algorithms to verify that the file has not been modified in any way, and the file is exactly the same as it was at the moment it was signed. When this is confirmed, the second step is to check whether the particular signer is actually trusted by the system. The system’s certificate store is consulted and the chain of trust is verified.

However, as it turns out, there is a problem in the first step. A signed executable can be modified in such a way that it uses/executes a modified (and possibly malicious) part of the code, yet the file’s signature still remains valid. This destroys the key property of digital signatures – ensuring that a signed file has not been tampered with.

So, what are the consequences? Are digital signatures really that critical? Signing of executable files has become more and more important in the past years; many programs and services have gone online, the amount of malicious files on the Internet has grown vastly, and the social engineering techniques attempting to deliver those files to the victims have only improved. Digital signatures make it possible to distinguish between files coming from trusted sources and those faked by a malicious attacker. In 64bit editions of Windows operating systems, Microsoft has gone even further by enforcing special signing of driver files, with the goal of preventing installation of anonymous/unauthorized kernel code into new systems. (Note that we did not find any evidence that this discussed vulnerability also affects driver verification code – it seems to be safe.)

When you download a file from the Internet and try to run it, or when the UAC prompt appears announcing that a program needs to be run with administrator privileges, the digital signature is checked and the name of the signer is displayed. However, if you cannot be sure that the file is genuine, you can’t really say “this file comes from the company I trust, it’s OK to run it”. Or, to reverse the situation, if a fake file is signed by a known company and you are presented with that information by the operating system itself, there is a very good chance that you will fall for that trap and run the file – a much higher probability than if the file was signed by somebody unknown or wasn’t signed at all. So this vulnerability gives malware authors a chance to increase the perceived trustworthiness of their creations, and subsequently increase their distribution.

Another possible scenario is an Evilgrade-style attack. Many current applications (browsers, browser add-ons, PDF readers, Java, Windows itself) automatically check online for their updates – which is good, because it speeds up fixing of other vulnerabilities found in those programs. When an update is found, it’s downloaded, verified, and finally installed. Why the verification step? First, to make sure there wasn’t any corruption during the file download, and second to check that there wasn’t any network redirection (either local, such as a HOSTS file hijack, or remote – by an evil ISP or hacked router) and if the file wasn’t actually downloaded from a completely unrelated location.

How do they do such verification? Yes, checking the digital signature of the downloaded file is a natural choice. But, if it’s possible to fake the content of the file and keep the digital signature valid… we have a problem; imagine a rogue ISP serving fake browser updates to all the connected clients, installing arbitrary code on their machines. This rogue “ISP” might range from a simple WiFi hotspot placed in a public place to a whole country with the government controlling the Internet connectivity – and trying to get into the people’s computers as well.

Even security products themselves might be affected. Checking the digital signature of a file and assigning that file a certain level of trust according to the outcome – that’s a fairly common practice. Applications signed by specific trusted vendors might get whitelisted – either for certain operations or completely. But of course, it’s imperative that the file in question really originates from the expected vendor; if it was modified by a 3rd party, the trust is unjustified.

As we can see in the few examples above, not being able to trust digital signatures of executable files can be a serious problem. So, what now? The patch is released, everyone installs it and we are back in the world where all is fine again? Well… mostly. The thing is that there are multiple ways to modify signed executables. Some of them can be easily detected because the resulting files are so twisted that no one would ever create such a file without actually trying to exploit the vulnerability. Others are harder to avoid because they are not enabled by any bug in Windows code – they are partly a design flaw (and since we are talking about the format of executable files and digital signatures, it’s something that cannot be easily changed because it would invalidate millions of signed executables out there), and partly a bug in the modifiable executables themselves (i.e. a problem in those 3rd party applications susceptible to this kind of attack). And while the patch tries to do its best to prevent even those harder-to-detect methods, there likely are some applications out there that still can be tampered with while keeping their signature valid.

We have not found any malware using this vulnerability prior to the release of the patch (we have run multiple probes across our 150m+ strong user base to get some intelligence on that). However, we have discovered a few companies that use it in their legal (non-malicious) files – most likely to avoid repetitive signing. Those companies might be in for a little surprise – because their files won’t be signed anymore after the patch is installed (i.e. the signature on these files won’t be verified on systems where the patch is present). This is not to say that you shouldn’t install the patch – you certainly should! The files in question are not “properly signed” anyway.

To conclude – you can never be too careful when it comes to downloading and installing programs. Even a digital signature by someone you trust doesn’t give a 100% assurance that the file is safe. The reason doesn’t even have to be the vulnerability discussed here – the signing certificate may have been stolen, the company computers may have been infected by a virus that embedded itself into the file before the signing, a certificate authority may have been hacked and a fake signing certificate created by the attacker; we have seen all of those. So, don’t download files from suspicious sources, always double check where you download files from, keep your system up-to-date – and use a good antivirus that protects your computer from similar attacks.

Read the original here:
Beware of a new Windows security vulnerability (MS12-024)

Kaspersky Labs Int. comments on the recent virus incident Cambridge, UK, October 28, 2000 – As disclosed on Friday, the corporate network of Microsoft, the world’s largest software developer, was attacked by unknown hackers. The hackers used the QAZ network worm to penetrate into the network. As a…

Read more from the original source:
Microsoft Corporate Network is Hacked. What About Your Network?

Darkshell is a distributed denial of service (DDoS) botnet targeting Chinese websites. It was found in 2011 and was first analyzed by Arbor Networks. McAfee Labs recently analyzed a few new samples that turned out to be variants of Darkshell, and we found extensive variations in network traffic and control commands.

The Darkshell bot follows a fairly standard installation process by copying itself into the System32 directory with a name that appears to be legitimate, for example, C:WINDOWSsystem32WinHe803.exe. It then sends the system information of the infected machine to its control server in encrypted format. Once the control server receives the information, it responds with the victim’s address and the type of DDoS attack to perform.

Here are a few of the MD5 hashes we analyzed:

• aff00fac695971c1aea37ce51f4d6228
• beec4de4740da867ed44c666d283c4f2
• b3e28fc05514abbaea1e12b676bef2a8
• bc47ff49ba8ea1bc0c028edd7262c0ac
• bcb210972648719e7d53223fbb7210ab
• beec4de4740da867ed44c666d283c4f2
• bf56f97511c4c4bc23d92c17d5e976fe
• c008c851bef86764943f7a4a2a16d7c6
• c74890f5a5400e70ff40da0493a933d7

If you use a computer and/or the Internet you might want to think twice about heading to the disco or the movies or whatever else you had planned for this Saturday night and spend the evening backing up your data instead. Why? Three reasons, starting with the fact that today is World Backup Day. Sure, World Backup Day is not as well-known as other days, like World Prayer Day, Earth Day, or even International Talk Like a Pirate Day; but it may be just a matter of time. After all, March 31, 2012 is only the second World Backup Day. Here's what the press release from WorldBackupDay.com says:

World Backup Day began it's inaugural celebration in 2011 by a few concerned users on reddit.com just a week before March 31st. After a fast and furious week of developing and designing, the World Backup Day holiday was born on March 31st. It was a hit in the tech industry with virtually all tech news sources reporting on World Backup Day. For 2012, World Backup Day has partnered with many media partners to promote the holiday. This is just the beginning for World Backup Day. World Backup Day will continue to grow and promote regular data backups.

In case, you haven't had enough coffee yet this Saturday and failed to make the connection: World Backup Day is set to be one day before April Fool's Day. Hence the slogan: Don't be an April Fool. Backup your data.

And there you have the second of the three reasons to consider spending your Saturday night backing up your computer, and smartphone, and tablet: Weird things happen on April Fool's Day, some of which could be damaging to your data. If you are wondering just how to do your backup, my colleague Aryeh Goretsky has created an easy-to-read guide to your Options for backing up your computer (free .pdf, no registration required). In just 11 pages, Aryeh covers both backup technology and strategy for the consumer and small/home office.

The third reason to consider staying this Saturday evening to do your backup that one of the weird things that might happen on this April Fool's Day concerns a shadowy group of self-proclaimed hackers who have talked about shutting down the Internet tomorrow (there is comprehensive coverage of this threat and the wider topic of hactivism here and of the technical aspects here). Personally, I don't think that the Internet will go down this April 1, but I would be remiss if I didn't point out the challenge that the very idea of an Internet shutdown poses to an increasingly popular form of data storage and backup: The Cloud.

In fact, some people first got to know The Cloud as online backup. Services like Mozy and Carbonite have been around for some time, offering the ability to send a copy of your data over the Internet to someone else's much bigger computer for safe-keeping, and getting it back from there if your own copy gets damaged or go missing.

A more recent variation on online storage is to use the Internet to enter your data into documents that are born and stored on someone else's computer, notably Google Docs. I know of some companies that have no file servers and very little local data storage in their offices because all of their reports, presentations, and spreadsheets are on Google Docs. I'm thinking that this World Backup Day might be a good time to pull down local copies of all that stuff “just in case.” Go into Google Docs and:

1. Click the checkbox(es) next to the item(s) that you'd like to download.
2. Expand the More drop-down menu and select Download…
3. Select a file format to which you'd like convert and download your item, such as Microsoft Word. When multiple items have been selected, they'll be compressed into a .zip file
4. Click Download

Note that if you try to export more than 2 GB at a time, you'll see a message from Google with a list of files that aren't included in the zip file. An alternative is to use a piece of software that will back up all your Google docs at once. One example is Backup Goo which comes in three flavors: Windows, Mac OS X, and Linux. (Disclaimer: use at your own risk, I have not tested it yet as my own Google docs take up less than 2 GB.)

I know it's Saturday, so I will keep this short by avoiding speculation about the threatened demise of the Internet. I have no doubt that the “right” combination of talent and numbers could bring the Internet to its knees. I personally doubt that will happen this year and there are some good reasons to think it won't ever happen. But I am sure there will be, if not tomorrow then fairly soon, one or more of the following: earthquakes, fires, floods, hurricanes, tornadoes, and other data-damaging acts of god and man. I truly hope you don't experience any of them, but if you do, you will be glad you have backups.

Here is the original post:
Saturday Night Backup Fever, Internet Apocalypse Now

We’ve looked at the importance of “Patch Updates” recently and focused on Microsoft’s Patch Tuesday, when Microsoftprovides users with often very essential updates to its Windows operating systems. When serious flaws or security loopholes open up, they need to be patched with remedial software code and the update process for most users is quite automated and comparatively simple.

But it is important to note here that patching goes beyond Microsoft and beyond operating systems.
For companies who employ a formal IT manager role, the process of engineering patch detection into regular systems management is crucial. Patch detection should also be linked, from a process perspective, to patch distribution. Itsounds obvious, but there is little worth in identifying security vulnerabilities if they are not subsequently mitigated against.

For businesses looking to deploy what might be classified as an “end-to-end solution” that will comprehensively look after vulnerability and patch management, there are certain provisos and caveats to be aware of.
For small to medium sized businesses without a full time IT manager, there are lessons in security best practice here that are still universally relevant.

This is a virus-worm that spreads via the Internet attached to infected e-mails, and copies itself to shared directories over a local network, and also attacks vulnerable IIS machines (Web sites). The worm itself is a Windows PE EXE file about 57Kb in length, and is written in Microsoft C++. In…

See original here:
Information about the Network Worm "Nimda"