SophosLabs blog

Free virus scan - Download a Sophos Security Scan

From Nigeria with Love - old sk00l spam

Every now and then we at SophosLabs receive a sample of malware or spam that (laughs aside) shows the true inventiveness of the spammers and malware authors.

During the World Cup I received some SMS spam on my phone but this week’s spam sample was even more sophisticated! (And by sophisticated, I mean lowbrow, grass-roots, snail-mail con-job, low-tech and yet probably more effective than regular email spam.)

I mean, what spammer would spend the time to type up a letter using some official looking letter head, sign and stamp it to add that official feel and even pay for postage! Dedication++ suggests the tangibility and effort might be paying off - but how different is this from your regular run-of-the-mill email spam (apart from the much reduced volumes)?

Fancy stuff aside, the letter boils down to the following 419 cliché - A random barrister is asking you to commit fraud in order to claim an inheritance of a sizeable amount of money, and of course the transaction and details are of utmost secrecy. It even has an apology incase you’ve been offended by the idea of committing fraud to pocket someone else’s cash!

Divulge your details and I assure you the only thing you’ll be getting is likely to be a call from your bank manager.

Now I guarantee that no anti-spam product on the market will stop this type of campaign. Luckily, due to its nature, it is of low volume - however, if you have received such a request, you may wish to have your local federal investigators examine it, or utilize the SophosLabs approved in-house anti-spam solution as shown below.

Posted on July 30th, 2010 by Pete, SophosLabs AU
Filed under: General

                                         

How large is a piece of Malware?

Q. What is the average size of a typical malware file?

Of course there is no definitive answer to this question, and different kinds of malware can have vastly different sizes, but for those wanting an answer I ran a quick calculation over some of SophosLabs’ monthly collections of malware samples.

In January 2005 the average size of a malware sample was 126 kB. In June 2010 it is 338 kB.

This growth in size is pretty much what one would expect, and can be for several reasons. Long gone are the days of hand crafted assembler code designed to be as small as possible. As computer memory, disk space and internet bandwidth grow, so does the output of a typical compiler. Software libraries become larger, and software (both legitimate and malicious) tends to contain increasing amounts of complexity and functionality.

Q. Can you give some examples for specific kinds of malware?

Troj/JSRedir-BV is an obfuscated Javascript, typically seen attached to spam email messages. If the attachment is opened the web browser will be redirected to a scam web site. Such redirection could be done in one line of Javascript, but due to the heavy obfuscation used a Troj/JSRedir-BV script is typically 3 kB to 5 kB in size.

Mal/Dloadr-Y is a downloading Trojan with functionality to change firewall settings, download a configuration file from a remote website, then download further malware as dictated by the configuration file. Samples of Mal/Dloadr-Y are typically 25 kB to 30 kB in size.

FakeAV Trojans are rogue anti-virus applications that display fake infection warnings to try and scare users into paying for cleanup. There are many different families of FakeAV, and even within a family there can be a large variation in size. For example, samples of Mal/FakeAV-DO range from about 300 kB to over 1 MB. These variations are partly because FakeAV authors frequently change packing or encryption techniques. Furthermore, in some cases each sample contains random amounts of junk data in an attempt to evade detection.

Viruses, although often relatively small in themselves, can infect legitimate applications of any size. For example, a typical variant of W32/Scribble-B contains about 20 kB of viral code, but infected applications can be just a few kilobytes or many megabytes in size.

W32/Scribble-B also injects a malicious iframe into htm, php and asp files. The iframe is just one line of html (about 80 bytes) but the infected web pages can be of any size. However, the iframe is always added at the end of the file, so it is easy to find and is detected as Troj/Fujif-Gen.

Q: As Malware gets larger, does Sophos’ scanning get slower?

From a customer point of view, this is the wrong question. Whilst SophosLabs has an ever increasing collection of malware (and increasingly powerful hardware to extract and analyze lots of data from it) the existence of malware on a customer machine should be a pretty rare thing. If the virus engine spends a few milliseconds identifying a malicious file that is no big deal. What matters is that it scans over a typical clean file in not milliseconds but microseconds. So the real question is: as legitimate software gets larger does SAV get slower?

Actually, individual file size has very little impact on Sophos’ scanning speed. Here in the labs we put a great deal of thought into optimizing the performance of our detection identities. Instead of linearly scanning through whole files for fixed patterns, each identity targets only those parts of the file where it needs to look.

To take an analogy, suppose you have misplaced your cell phone. Rather than starting at one end of the house, and slowly working your way to the other, searching everywhere with a fine comb, you probably stop and think: Where am I most likely to have left it? Where did I last use it? Where have I been since then? There is no need to check the attic if you haven’t been up there all week. Quite quickly you will identify the most important places to look. Even better, if you have access to another phone you can call your cell phone, and listen out for where it is ringing from.

Sophos’ identities use all sorts of shortcut techniques like that. For an executable file, one obvious place to check is the point from which code execution begins. The virus engine automatically loads some of this code, and many identities start by checking it. If it doesn’t match an expected pattern then it doesn’t matter whether the file is 10 kB or 10 MB, many identities don’t need to look any further. Even identities designed to detect such nasties as polymorphic (changes every time, so there is no fixed pattern to look for), mid infecting (viral code is not at the entry point) viruses use a clever combination of emulation and statistical pattern checking to only scan in a few key places.

Q: Is there an upper limit on the size of file SAV scans?

I was quite surprised to learn that some AV scanners have quite stringent limits like this, presumably in order to optimize their scanning performance. Some even have a configurable global setting where you can chose between a low limit (better performance, but risks missing some malware) or a higher one (finds more malware, but slower scanning.)

That is far from ideal. We have already seen how different malware families tend to have different sizes. So in SAV, instead of a global file size limit, each individual identity can (if necessary) specify appropriate limits according to the kind of malware it is trying to detect. As we have already observed, an identity to detect a virus has to scan files of any size, but can be optimized by knowing what to look for and where to look. Meanwhile, many generic identities to detect particular malware families can make use of size optimizations. A typical family of internet banking Trojans might be, say, between 3 and 4 MB. That is just one of several pieces of information that an identity might use to quickly eliminate 99.9% clean files from further scanning. Further investigation will only happen on those files that warrant it.

If we start to see new variants of that family increasing in size then SophosLabs can at any time issue an update with new size ranges. Similarly we can update many other checks to reflect the changes we are seeing. That is the reason why many of our generic detections ask customers to send in samples. Even when we proactively detect a new sample, we want to keep monitoring trends and staying one step ahead of the game.

So Sophos customers do not need to worry about typical size of malware files, nor do they need to worry about setting file size limits. SophosLabs is always monitoring the trends, and making any necessary performance decisions for you.

With the recent launch of SAV 9.5 the labs are getting more data than ever before. Whenever a generic identity detects a file, the size of that file is one of the key pieces of data that can be automatically sent back to SophosLabs. Automatic feedback only happens if customers consent to that option, but we have been very pleased by the number of customers turning it on. Sophos is already a leader in proactive detection, and with this new feedback data we can fine tune that detection to be even better! Thank you for helping us to help you.

Posted on July 27th, 2010 by Robert, SophosLabs CA
Filed under: General, Malware

                                         

Australian Tax Refund Spam Again…

It is now Australian Tax Refund time again. And right on cue, spammers have re-emerged in producing phishing scams as they would never miss this opportune moment to steal money. So, what does this year’s taxation spam look like?

It appears the spammers have learnt one important lesson from past years and that is to stick to the Keep It Simple Stupid (KISS) philosophy. The scam message is only 732 bytes long and contains a few eye-catching phrases in both the subject line and the message body.

Hold on…. but where is the dodgy call-to-action? Where is the fake link? Where is the accompanying dodgy PDF document of yesteryears?

This time, it is nefariously hidden in the HTML attachment which contains only a simple meta refresh link. In this way, when the email is opened, the link in the message automatically (without any further user intervention) redirects the recipient to the following bogus Australian Tax Office (ATO) website, from where it will attempt to harvest the victim’s credit card information.

Will we be seeing more of these phishing scams? There’s no doubt we will. Be it from the UK or the USA, it appears that tax time is a very lucrative opportunity for spammers and phishers. As usual, it is wise to be extra careful of unsolicited emails, especially those that appear to come from the government.

And yes, SophosLabs has already blocked this kind of phishing scam.

Posted on July 27th, 2010 by Rowland, SophosLabs AU
Filed under: Spam

                                         

Why won’t my sample run?

Here at SophosLabs we have recently been seeing samples of Zbot (also known as the Zeus crimeware kit) that refuse to execute on any of our testing machines.

Often when this happens it is because the sample is corrupt or will only execute on specific versions of Windows, or maybe because the file will only run on a specific date, or because a certain payload is only activated on a certain date (e.g. CIH).

However, these Zbot samples have been crafted to ensure that they only work when executed on one specific machine and from one specific path. Any attempt to execute the sample on a different machine or from a different path will result in early termination of the malware and no impact on the target system.

 

This is achieved through a form of hardware based digital watermarking that makes dymanic analysis of the sample effectively impossible for AV researchers.

 

Older versions of Zbot (pre version 2.0), when first installed would copy their executable to a fixed location (%SYSTEM%\sdra64.exe), sometimes appending random amounts of data to the end of the file to avoid checksum based detections. Version 2 creates a new file with a random file name inside a new folder under the user’s %APPDATA% directory. It then deletes the original file with a batch script.

The new file is almost identical to the original file except for a small block of encrypted data at the start of the “.data” section. This block contains the hardware and pathname information that ties the sample’s successful execution to one location on one machine.

 
The block contains several key pieces of information including:

• A string that includes information from the Computer Name and DWORD values generated using the OS install date and product key.
• A GUID generated using GetVolumeNameForVolumeMountPoint and CLSIDFromString.
• The randomly named directory and exe file that the new file will be dropped to.

 

 

The block is then encrypted using RC4 and embedded into the new file which is written to disk and executed. When the new file is executed it decrypts the block, re-computes the GUID based on the information from the machine it is now running on, compares it to the decrypted value and exits if they differ. The current path of the executable is then also checked against the decrypted path information from the block.

So when the malware sample is discovered on the machine and sent off for analysis it will be executed on a new machine and generate a new GUID based on different hardware and OS information, which will fail the comparison and result in a sample that does nothing, causing AV researchers to scratch their heads and wonder what’s going on.

 
This sophisticated technique is very similar to hardware based licensing systems employed by major software companies to protect their products from piracy. But until now I had not seen the technique used to protect malware binaries from analysis.

Fortunately Sophos customers are protected by Mal/Zbot-U.

Posted on July 24th, 2010 by James Wyke, SophosLabs UK
Filed under: General, Malware

                                         

Some Zbots just can’t move on …

Zbots have been recently going through several changes in their infection method and functionality. One of the new samples though, caught my attention due to its naïve evasion tricks.

First the old static analysis mangle

The correct offset of the push below should be 0×0041b22d but IDA thinks this doesn’t make sense

so it decides that an instruction that makes sense is at 0×0041b22b which confuses disassembly after that. This though is a very old trick that happens to be easily repaired as the correct offset is in the byte code. So going to the correct offset and forcing a code analysis from there would fix the problem.

Another old trick is the use of the rdtsc instruction for anti-debugging , this time though its used as an anti-emulation trick !

As seen below the rdtsc is called twice and the results compared to check the time difference. This “time” is actually a representation of the number of CPU cycles executed since the processor was started . Normally the compare instruction would be there to check if the number of cycles is too large between the two rdtsc instructions , thus a debugger is being attached to the process. In this case though, its used as a weak anti-emulation trick as the actual processor would populate the registers accordingly, some emulators though wouldn’t , thus the jump instruction would always succeed due to the mov in between .

Upon detecting that it is being emulated it jumps to an invalid memory read instruction to cause an exception.

Sophos detects this threat as Troj/Zbot-TG .

Posted on July 19th, 2010 by AhmedZaki
Filed under: General

                                         

Malware exploiting x86 machine code redundancy

Every AV product on the market in these days is furnished with an emulator which provides a safe sandbox for running executables files, before they get loaded and executed in the proper environment. By definition an emulator will never be exactly like ‘the real thing’, and malware authors continually try to exploit this fact in order to evade detection.

In that sense x86 machine code is not helpful for us, since it allows certain assembly instructions to be encoded in different ways. A nice list of some of these tricks can be seen here .

While analyzing in IDA the dropper component of a pretty famous rootkit, it was quite obvious that something weird was going on.

Courtesy of the square bracket at the end of the mov disassembly listing I could notice that
the SIB byte ( 0×25, 0×65, 0xA5, 0xE5) was used although it doesn’t have any real effect.
You’re free to swap those bytes and if you are in the mood of fixing the offsets of the code
around, you could replace it with a shorter encoding.

It’s quite evident that this is done intentionally in order to break emulation, since this sequence of mov instructions is at the entry point of this dropper, while a similar piece of code in this very same sample uses a more standard encoding.

Posted on July 17th, 2010 by IvanSpeziale
Filed under: General

                                         

July 2010 Patch Tuesday

There are four new releases in this months Microsoft patch release, of which the stand out item must be MS10-042 which is a fix for last months 0-day (CVE-2010-1885) which we saw a number of exploits for.

Although none of the others are rated higher than medium risk by SophosLabs users are still urged to apply these updates as soon as possible.

For the full details of this months updates and links to Microsofts own advisories check out our vulnerabilities analysis page.

Posted on July 13th, 2010 by Cliff Wright
Filed under: Exploits

                                         

“The chase is better than the catch”, perhaps not always

AntiVirus users may not be aware just how much effort malware authors put into their creations.

The main aims from that side of the fence are to design malware that:
- will avoid any existing detections when first released
- must be easy to update, so that detections too specific can be avoided with new releases

The global strategy of these gangs consists of trying to make a single piece of malware last for as long as possible, making few changes on each update, in order to maximize their ROI.

For us the challange lies in identifying the base building blocks, that are not going to be changed, and thus provide a proper generic detection.

This week I stumbled upon a couple of Fake AV samples, from which you can
clearly see the ‘update as less as possible’ scheme in action.

In the first sample you can see how a value is assigned to both the variables in
an obvious way.

The second screen is taken from a more recent sample, in which the assignment to
var_8 is done in a different but still straightforward way, relying upon a specific
error code returned after the call to an API with specific parameters.

An analyst knows that this code will change again, with new APIs and other fancy tricks,
that’s why the key to success in catching malware is to anticipate future changes.

Posted on July 8th, 2010 by IvanSpeziale
Filed under: General, Malware

                                         

Spammed redirects using anti-emulation tricks

A few weeks ago Richard posted a blog about malicious HTML attachments we were seeing in spam. Well, the attacks have continued since then along much the same lines. For example:

Current attachments are being blocked as Troj/JSRedir-BV.

As noted before, if the victim opens the HTML attachment, the embedded script will run within the browser, and redirect them to a another remote web page (hosted within a legitimate but compromised site). Sophos products block this page as Mal/Iframe-Q. From there, the attack is two-fold:

• META redirect to some spammy site (Canadian Pharmacy and similar)
• malicious IFRAME loading further content from another site

In this post I wanted to highlight one of the tricks used in the malicious JavaScript within the HTML attachments. The script is minified and peppered with junk code, hindering readability, but after prettifying and removing the junk code, it is fairly simple. The decryption function is called via setTimeOut, and consists of a simple xor.

There is a cunning little trick in the script, designed to break JavaScript emulation tools. By calling the decryption routine via setTimeOut, the script is able to ensure there has been a sufficient delay. Most emulation tools will tend to ignore the setTimeOut delay, resulting in an incorrect xor key being generated, and decryption failing.

When correctly deobfuscated, you can see that the script redirects the victim with a location.href:

These attacks are just another example of the growing number of tricks being used within malicious JavaScript to evade generic detection and hinder automated analysis techniques.

Posted on July 8th, 2010 by Fraser Howard, SophosLabs UK
Filed under: General, Web

                                         

Is pornography only skin deep?

Looking through news sites I encountered articles about a full-frontal pin-up calendar (“EIZO - Pin-up Calendar 2010″) that shows a young lady more exposed than any I have seen before. Yet this calendar is reproduced on various respectable websites. It is all part of a clever marketing campaign by LCD monitor manufacturer Eizo. Now after the initial laugh & giggle no one would seriously say that there is anything wrong or immoral about these pictures, but…

This strikes me as another one of those grey areas, literally shades of grey in this case. It is difficult to have a universal definition of what is legitimate for public consumption and what should be censored as pornography. Now obviously a skeleton of a woman is not pornographic, yet full-frontal pictures of a live woman in erotic poses is obvious porn. So when is an image unacceptably pornographic?

A little bit of exposed flesh is alluring, a lot is rude. If a picture can be pornographic when you can see the exposed outer micrometer of flesh, as displayed in PlayBoy magazine etc. Then is being able to see the rest of the flesh that is below the skin going to be more pornographic, or less? And what ever the decision, why?

Is it context that counts, as in the “is it art or is it porn” argument? In this case the erotic poses would suggest it is definitely pornographic. There is certainly no medical reason involved for these particular poses.

In some countries the laws have defined pornography as how much and what bits of flesh are exposed. The film industry suffered with actresses in bedroom scenes having the amount of exposed breast measured by a censor before shooting was allowed. Well these pictures certainly fail that test.

Sometimes laws define pornography as “that which may shock, offend or corrupt”. But that surely depends on who is present at the time. Some regions with this type of law allow people to walk to the local supermarket whilst completely naked, whilst others are very restrictive in their interpretation. So are these X-rays offensive or likely to corrupt you?

Legal definitions of pornography in general vary drastically. It can depend on where you are, what social group you are in, who you are with at the time, age, period of history, gender and so many other factors. In the end it usually comes down to the interpretation of an individual censor or judge.

If we have ruled out law, artistry & offensiveness as suitable definitions of what should define pornography then should it depend on it’s arousal. Should it be down to whether someone might choose to experience the material because of it’s sexual effect. After all that is what the other methods are trying to restrict, namely images or actions that might cause a sexual response. So do these X-ray images cause you to be aroused? Possibly an interesting question. But yet again there is the huge variance from person to person. After all there is Objectum sexuality or Objectophilia where some people get sexually aroused by everyday objects. So should Apple’s iBook be banned because of it’s potential erotic effect?

I still don’t know if technically these X-rays are pornography. Why do I care? Because it can be our job at Sophos to help protect you from pornography, if only we knew what it is.

And if this isn’t explicit enough for you there is also a MRI video of sexual intercourse penetration that is part of the results from a paper submitted to the British Medical Journal some time back. Though this example is not pornography as it is medical research, lucky scientists.

Posted on July 5th, 2010 by JohnBryan
Filed under: Web