On March 4^th we spotted a large number of unusual emails being blocked by our Linux Mail Security product. The emails all contained the same PDF attachment (MD5: 97b720519aefa00da58026f03d818251) but were being sent from many different source addresses.

The emails were written in German and most were sent from German IP addresses. Below is a map showing the distribution of addresses:

The computer names referenced in the mail headers were often of the form Andreas-PC or Kerstin-Laptop (the names have been changed to protect the innocent) suggesting that they had been sent from German home computers.

This is the topic that cybercriminals are speculating about and using as a hook to infect victims. The campaign stems from malicious emails that are sent in bulk to victims:

In information security, talk about botnets equals talk about malicious actions that materialize through criminal action. In essence, we think there is always a hostile attitude on the part of those who administer them. Please correct me colleagues, refute this if I'm wrong, but I think conceptually you agree with me.

BoteAR (developed in Argentina) adopts the concept of "social networks" although it seems, as yet, not fully materialized. It offers a conventional and manageable botnet via HTTP but uses the model of crimeware-as-a-service. Moreover, the author seems to adopt (maybe unknowingly) the business model of affiliate systems originating in Eastern Europe which are used to spread malware i.e. infect and get revenue for each node you infect.

So far nothing unusual, unfortunately we witness this kind of tactic every day. The striking thing about BoteAR though is that it tries to shield itself under a wrapper of security in an attempt to "fraternize" with its community.

Recently, we came across web malware that – instead of injecting an iframe pointing to a fixed existing address – generates a pseudo-random domain name, depending on the current date. This approach is not new and is widely used by botnets in C&C domain name generation, yet it's not very common for the web malware we’ve seen so far.

After deobfuscation, we can see that the iframe redirecting to the malicious URL with generated domain name is appended to the HTML file. All URLs consist of 16 pseudo-random letters, belonging to the ru domain and execute PHP script on the server side with the sid=botnet2 as argument:

The infection strategies using java script technology are on the agenda and that because of his status as a "hybrid", criminals looking to expand its coverage of attack recruiting infected computers regardless of the browser or operating system you use.

In terms of criminal activities, the techniques of Drive-by-Download by injecting malicious java script in different websites, are a combo of social engineering that requires users to increasingly sharpen the senses of "detection".

During this weekend, we encountered a fake website of the popular system analyzes suspicious files Virustotal, by Hispasec company, touted to infect users through the methods mentioned above.

A new Twitter XSS exploit was identified in the wild as it started to be used by cybercriminals overnight.

The malicious JavaScript payload that's being distributed is rather simple. It uses an XSS (Cross-Site Scripting) vulnerability to steal the cookie of the Twitter user, which is transferred to two specific servers. Essentially, any account which clicked on the malicious links is compromised.

But how many people clicked the link? The bit.ly statistics for one of the malicious links are more than worrying, showing an alarming number: more than 100.000.

All clues point to Brazil as the originating country for this attack. First, the 2 domain names used to get the stolen cookies are registered under Brazilian names. More than that, one of them is actually also hosted in Brazil. Last, but not least, just take a look at the tweet used in distributing this malicious payload:

Pe Lanza da banda Restart sofre acidente tragico - it's a short tweet in Portugese about the Brazilian pop band Restart suffering a "tragic accident". I'd say there's not much doubt about the origins of this attack.

We've added detection for the malicious scripts as Exploit.JS.Twetti.a and also made sure the URLs used in this attack are blacklisted. We are currently working on taking down the malicious URLs and minimizing the damage as much as possible. Twitter along with other significant industry peers have of course been notified.

UPDATE: Twitter has confirmed the vulnerability is fixed now.

Today’s bank customers face the very real threat of losing their hard-earned cash if their online banking identities are stolen by cybercriminals. To help prevent online banking theft, many banks have begun issuing USB dongles and card readers to their clients as a means of proving their identities when online. When a client uses their online banking service, the bank’s website requires the user to identify themselves as the account holder. This is achieved by each user having a unique login which is checked in tandem with the information held on the dongle or entered via the card reader as and when required.

At first glance this system looks pretty watertight. Even if a cybercriminal steals a user’s online banking identity, they will not be able to use it if they do not have the appropriate card reader or token as well. However, some cybercriminals have managed to get around this. Some malicious programs force the legal user to authorize money transfers from their account to that of the cybercriminals’. We will use ZeuS, a popular Trojan, as an example of how this scheme works.

After establishing itself on a victim computer, ZeuS intercepts all of the data passing through the web browser. It may change the data, e.g. by adding malicious code to that of the site. In this case, the user will see the version of the site only after it’s been tampered with.

First, let us see how the account management system works normally, without a Trojan present. The user enters their login and password. If the data is correct, the system provides the user with access to their bank account(s). Whenever the user wants to transfer money, the banking system will require them to authorize the transfer by registering their identity card using the card reader connected to the user’s computer. This is the way the system has been designed by the developers.

...But the cybercriminals have a trick up their sleeve.

We recently came across a very interesting suspicious web page. The HTML page of course contained malicious code that linked to the Trojan. However, it was a separate HTML page inside the benign one - the authors of the code went against HTML standards, and put in an extra <html></html> container.

What's surprising is that browsers (we checked using Internet Explorer, Firefox and Opera) don't have any problem processing a page like this. On the other hand, who would expect malicious users to observe standards?

However, this isn't the main issue. We're interested in the script that the malicious users integrated into the web page. Of course, the script is designed to make analysis as difficult as possible, using techniques to obfuscate the JavaScript.

The script itself looks more or less like this:

Nothing particularly surprising here - the majority of scripts like this can be decrypted without analysing all the steps taking to manipulate the code. You just have to find the part of the code which prints to the original web page in order to run the payload. And in this case it's the document.write() function:

If we modify this, we can see the decrypted code for the payload. Change document.write(P7E87DE2) to textarea1.innerHTML=P7E87DE2, with textarea1 being the HTML textarea container on the copy of infected page that we deliberately created on a local harddrive. Now we can see what the script does in the textarea field. Which gives us the following:

And it seems that this script doesn't print anything. This is the first impression - but a closer look at the script turns up this string:

What does this mean? It's very simple - this function gets its own code, and transforms it into a 'key' text string which is made up of letters and numbers. Within the function this string is used to generate the payload i.e. what gets entered in the text area depends on the body of the function itself!

As a consequence, if the code is modified in the slightest way, the result generated will be completely different, and may be completely nonsensical - this is what happened on our first attempt. It's a sort of defense mechanism against modifying the body of the JavaScript function. I haven't seen anything like this before in JavaScript - it's pretty smart.

However, it's possible to get round all of this simply by getting the same string from outside the function, assigning the variable q2854da60, which should be contained in the key string, to the result.

If you're an analyst doing this, and you're trying to get the script from inside the encrypted code, then you might suddenly find that when you open a correctly crafted page in order to get the hidden contents of the script, the browser will freeze. I'll just stick my two cents in here, and point out that this is the moment when your computer will get infected.

The construction used by an analyst within the <textarea></textarea> tags is crafted in such a way as to not only infect users' machines, but also to infect the computer of an analyst who's trying to get to the payload code by printing it to textarea! The construction looks like this:

So if the code is placed inside the textarea container, the code will close the textarea tag and add an iframe container - the browser uses this to load an external script which contains the exploit Trojan that infects the system.

This example shows very clearly how virus writers are combating antivirus professionals who want to protect rank and file users. And if a virus analyst makes the smallest error, his or her machine will become infected. And that's one of the reasons that I love my job - because it teaches me that there's no room for error!