Are Anti-Virus Vendors Using Uploaded File Samples To Find New Command-and-Control Servers?
Last in a three-part series. Read Part I and Part II.
In a previous blog entry, I detailed ZeuS and related malware families – and I demonstrated just how easy it is to build your own botnet.
While building my own research botnets for the previous blog entries, I submitted samples to a well-known anti-virus (AV) site to check for AV coverage.
Imagine my surprise when all of a sudden I saw many incoming web requests to my command-and-control (CnC) server — from all around the world! Keep in mind that my botnet had only one member: a virtual machine in my lab. So why would I see inbound connections coming from Japan, Finland, Russia (and so on)?
What? How?
After an initial moment of confusion (and panic), I regained my composure and promptly trashed the CnC server. Then I created a new CnC server (on a different continent) and built a new version of the payload. Instead of embedding the new payload with the URL to the typical settings file, I pointed it to a text file on the CnC server containing the following text:
Hello. This is not a botnet. This is for research! Please move along…
I created two different bots for this test: one was a ZeuS variant, which we’ll call “Botnet A” (detailed extensively in my previous two posts). The other was from a different malware family that we’ll call “Botnet B”.
In this investigation, I used ip_loc.pl, a tiny Perl program I wrote to look up the geographic location and reverse resolution of an IP address. I have redacted the specifics of the IP addresses I detected and include only the location details.
Botnet A - ZeuS variant:
# grep botnet-a.txt /var/log/apache2/other_vhosts_access.log | \
awk '{print $2}' | sort -u | ./ip_loc.pl
xxxx.compute-1.amazonaws.com, Ashburn, Virginia, US
(no PTR), New York, New York, US<
(no PTR), Mountain View, California, US
xxxx.neoplus.adsl.tpnet.pl, Warsaw, Mazowieckie, PL
xxxx.dynamic.clientes.euskaltel.es, Bilbao, Pais Vasco, ES
xxxx.elisa-mobile.fi, Helsinki, Southern Finland, FI
xxxx.broadband.corbina.ru, Moscow, Moscow City, RU
tor-exit-nl1.privacyfoundation.dk, Amsterdam, Noord-Holland, NL
xxxx.jp, Tokyo, Tokyo, JP
xxxx.ovh.net, London, London, City of, GB
xxxx.pools.arcor-ip.net, Teningen, Baden-Württemberg, DE
norman.norman.no, Lysaker, Akershus, NO
(no PTR), Oslo, Oslo, NO
Botnet B – Alternate malware family:
# grep botnet-b.txt /var/log/apache2/other_vhosts_access.log | \
awk '{print $2}' | sort -u | ./ip_loc.pl
xxxx.pools.arcor-ip.net, Gundelfingen, Baden-Württemberg, DE
(no PTR), Derwood, Maryland, US
Now, I cannot claim to know with certainty who the owners are of most of these IPs. But I would be surprised if home computer users were scouring the public domain for new malware samples to analyze. This leads me to speculate that AV research labs in Tokyo, Helsinki, and Moscow, among other locations, were checking my callback URL. (That was clearly the case in one instance — an AV software vendor made no attempt to hide its identity.)
What does all this mean?
Obviously, some anti-virus vendors are using public-domain malware submissions to improve their detection capabilities. While this isn’t news, I think it is interesting that AV vendors are mining new malware sample in sandboxes to identify CnC servers so they can add them to their AV or URL-filtering signatures.
So … these guys are relying on voluntary malware file uploads to find new CnC servers? I am not sure that this tactic is reliable. Even worse, it appears susceptible to abuse or deception. For example, it seems that AV companies are focusing on specific malware families such as ZeuS — you may have noticed that my CnC server for Botnet B (the non-ZeuS one) drew only a couple of hits. Why focus only on ZeuS variants? What about other botnet families? Even more important, what about highly targeted, zero-day attacks?
My conclusions from the simple experiments in this series of posts are as follows:
- Finding a botnet builder kit is very easy (in minutes).
- The botnet is very easy to deploy (in minutes).
- You can fool a large percentage of AV engines using off-the-shelf tools (in minutes).
- You can purchase previously unknown variants of the payload builders.
- If you take a little time with shellcode obfuscation or custom EXE packers, then you can beat more than 95 percent of the anti-virus engines.
- If compromising a chosen host is this easy using publicly available tools, it must be even easier for dedicated, focused attackers with significant resources supporting them.
Now that the Carberp source code has been leaked, I expect to see a number of new variants, undetectable by AV engines, surface in the coming weeks.
I also expect that the Carberp source is being poured over by many malware researchers in the AV industry who are looking for heuristic hits they can use to detect Carberp variants being uploaded to VirusTotal. And I’m sure the same thing will happen for the CnC servers found in these samples.
Final thought:
The techniques outlined in this series of blog entries are very simple and in no way reflect the real level of sophistication available to a determined attacker. I was only demonstrating by example how easy it is to compromise a host using a well-known builder kit of a well-known malware variant.
For the future, the world needs a platform that is not dependent on a priori knowledge of any of the stages of a targeted attack — one that goes beyond the mere sandbox analysis of discrete objects, and is able to detect web-based exploits that are used to hide the latter stages of the attack.
(Spoiler alert: you can find such a platform on this very website.)
