Twitter API Still Attracts Hackers

A few weeks ago I blogged about hacked sites where malicious scripts used Twitter API to generate domains of new attack sites and trigger “drive-by” downloads.

As you might remember, I mentioned that the script was buggy (failed to work on certain days) and the approach didn’t look viable in the long term since it required that hackers manually register one new domain name every day. As a result, in November, this vector looked abandoned (I couldn’t find active and even registered malicious domains).

However, hackers seem to be die-hard fans of Twitter and don’t want to give up on the idea.

A few days ago I found a blacklisted site, where search.twitter.com was mentioned as an intermediary in malware distribution. Safe Browsing diagnostic pages also mentioned fresh (beginning of December) malicious domains that were definitely generated by the above-mentioned script. No wonder, on the infected site I found the familiar script. Actually, it was not the same script. It was an improved version of that script.

So what’s new?

The malicious scripts are no longer injected directly into web pages. To make the initial detection harder, hackers inject their scripts into external .js files.

$a="Z64zZ3dZ22Z2566uZ256ecZ2574ionZ2520Z2564w...<removed part>...}return unescape(r);}eval(z($a));

The idea remains the same. Malicious scripts on hacked sites request trending topics from Twitter (using their API) and then use this information to generate a pseudo-random domain name of a currently active attack site on the fly, and finally inject a hidden iframe that silently loads malware from that site.

Two Twitter API requests instead of one

However, this time they use two consecutive calls to Twitter (was one).

The first request goes to

http://search.twitter.com/trends/daily.json?callback=callback

The response contains a timestamp (current time) and hackers use it to calculate a date (2 or 3 days before the current date) for the next API request.

http://search.twitter.com/trends/daily.json?date=yyyy-mm-dd"&callback=callback2

where yyyy-dd-mm is the calculated date. This request returns the top 20 trending topics for each hour in a given day.

New algorithm

The algorithm of the domain name generator has changed. In the previous version, as a key of the cypher, they used the second character of the most popular Twitter search on the calculated date (using the trends/weekly API). The algorithm generated one new domain every day.

Now they use

• trends/daily API and no longer exclude hashtags
• to generate 2 new domain names every day
• using the second character of the 5th most popular Twitter search for specific hours (7a.m and 6p.m.) on the calculated date.
• and they rotate the two domain names twice every day.
  • 0a.m.-9a.m. UTC – 1st domain,
  • 9a.m.-9p.m. UTC – 2nd domain
  • 9p.m.-0a.m. UTC – 1st domain

And in this version, they have fixed the bug that I noticed last time. (As far I as know, this was at least the second attempt to fix the bug, but the previous fix intoduced a similar bug in another place. This time they seem to have finally done it right.)

Online domain name generator

I won’t bother you with the technical details of this algorithm. Instead, I created a front-end to this algorithm where anyone can see the current and upcoming malicious domains.

It is called “Torpig Domain Generator” as some people believe that the Torpig(Sinowal/Mebroot) botnet is behind this attack.

This simple online tool is based on the scripts that I found on compromised web sites. I just deobfuscated it, removed the malicious part and slightly refactored. The core of the script is the same: two twitter API calles and the domain name generator, – so until hackers change the algorithm once again, at any given moment my online generator should produce correct information about active and upcoming malicious domains.

The implementation of the generator is JavaScript-base, so, if you are interested in the algorithm, you can find it in the HTML code the web page. As since it is JavaScript based, in order to see it working, you’ll need to allow scripts from UnmaskParasites.com and twitter.com.

Information about the malicious domains.

You can easily distinguish domain generated for this attack. In any given month their names end with the same 3-letter string. E.g in December they all end with “twe” (gabtibbgtwe .com, wghfqlmwtwe .com, etc)

• uno – January
• dve – February
• thr – March
• fir- April
• vif – May
• xes – June
• ves – July
• ght – August
• eni – September
• etn – October
• lev – November
• twe – December

Right now the attack is active and hackers register a couple of new domains every day. Here are just a few of them (mainly for webmasters of blacklisted compromised sites who can spot these domains on Google’s Safe Browsing diagnostic pages)

1. wghfqlmwtwe .com registered on Dec 03- google diagnostics
2. oderkayotwe .com registered on Dec 03- google diagnostics
3. derkaymtwe .com registered on Dec 03- google diagnostics
4. ghplzwgtwe .com registered on Dec 03- google diagnostics
5. wdecfjiwtwe .com registered on Dec 04 – google diagnostics
6. bcplcwytwe .com registered on Dec 04 – google diagnostics
7. aefjchpatwe .com registered on Dec 05- google diagnostics
8. mhjqxaxmtwe .com registered on Dec 05- google diagnostics
9. mhjvjcdmtwe .com registered on Dec 06- google diagnostics
10. gefjcrpgtwe .com registered on Dec 06- google diagnostics
11. gabtibbgtwe .com registered on Dec 07- google diagnostics
12. sfgtilbstwe .com – registered on Dec 07 – google diagnostics
13. sabtibbstwe .com – registered on Dec 08- google diagnostics
14. sdehpkostwe .com – registered on Dec 08 – google diagnostics
15. jdemastjtwe .com – registered on Dec 09 – google diagnostics
16. sjirktystwe .com – registered on Dec 09 – google diagnostics
17. aefnmvuatwe .com – registered on Dec 10 – google diagnostics
18. jbcfqmmjtwe .com – registered on Dec 10 – google diagnostics
19. aghuvfcatwe .com – registered on Dec 11 – google diagnostics
20. wderkhywtwe .com – registered on Dec 11 – google diagnostics
21. jefdrfkjtwe .com – registered on Dec 13 – google diagnostics
22. mhjvjcdmtwe .com – registered on Dec 13 – google diagnostics
23. ocdvjxdotwe .com – registered on Dec 13 – google diagnostics
24. qefswxaqtwe .com – registered on Dec 14 – google diagnostics
25. cbcfqvmctwe .com – registered on Dec 15 – google diagnostics
26. qcdlncsqtwe .com – registered on Dec 15 – google diagnostics
27. shjgdjnstwe .com – registered on Dec 16 – google diagnostics
28. ughplwwutwe .com – registered on Dec 20 – google diagnostics
29. ajicfjiatwe .com – registered on Dec 22 – google diagnostics

For more, check my online domain generator

As you can see Google is pretty good at detecting and blacklisting such short-lived malicious sites.

Whois

When I check the whois records for those domains I see that most of them have been registered with Register.com using fake (or stolen?) identities (addresses from all over the US) and probably stolen credit cards.

One interesting detail is they always use toll-free “+1.800…” and “+1.866…” phone numbers.

Sometimes I see a strange behavior when those throw-away domain names change their owners several days in a row, still pointing to the same IPs.

The domain names are really throw-aways. Many of them have already been canceled just after 2-3 days of use.

Malicious servers

When I started to investigate this incarnation of the attack, all generated domains pointed to a server hosted by CariNet. However, on December 7 I noticed that the server went down (probably because of an abuse report). A couple of hours later, the domains moved to a new server (216.245.219.178) on the Limestone Networks. It looks like not only do those guys have creative programmers, they also have a decent maintenance team.

Anyway, with their current approach of open domain name generating algorithm, the viability of the attack in the long term is questionable.

• new sites can be blacklisted by security solution providers even before they start to serve malicious content
• the domain names can be pre-registered by “good guys”, which can effectively stop “drive-by” downloads since the malicious scripts on hacked sites that generate new domain names have no “plan B” to handle such situations.
• the domain names can be hijacked (pre-registered) by another gang of hackers who can (temporarily) enjoy free traffic from their competitors.
• this approach assume a lot of ongoing support and manual operations. Hackers should track Twitter trends and register two new domains every day (BTW, can domain name registration be automated?)

It looks like hackers are aware of theses downside and they are currently testing a new approach with intermediary servers that redirect requests to pseudo-random domains generated using the Twitter API. This way they can gradually hide the domain generator logic on their proxy servers so that we won’t be able to predict new malicious domains when they change the algorithm. More about the new approach with proxy server in the upcoming blogpost. Stay tuned…

To webmasters

If Google blacklists your sites check the diagnostics page (there is a link from the warning page). If it mentions search.twitter.com as an intermediary or you see any other domains that end with “…twe.com“, most likely this article describes your case.

To find the malicious script that caused the malware warning, scan all your web pages and external .js files for code that starts with “$a=”Z64zZ3dZ22Z2566u…” or “$a=”Z64dZ3dZ22q…”

I still don’t have any reliable information about how this code is injected into legitimate web site. However, after analysis of the hacked sites, I’m almost sure that vulnerabilities in popular web applications are not to blame (many sites used only static HTML pages).

This can be yet another attack that uses stolen FTP credentials:

• I’ve seen several web infected websites managed by the same webmaster;
• some of the infected sites were also infected with Gumblar scripts and with hidden iframes (both infections use stolen FTP credentials)

so it’s always a good idea to change all site passwords and keep them secure. At the same time you shouldn’t forget to scan your own computer for malware.

Another hypothesis is this can be an infection that spreads across websites (probably with insufficient security settings) on shared servers. As I tweeted a few days ago, for some reason many known infected web sites are hosted by Aruba.it (but because of their distributed DNS configuration (every domain points to 8 IP addresses) I can’t say for sure if the infected sites physically reside on the same server.)

Once you clean up your site, you should request a malware review via Google’s Webmaster Tools to remove the warning from Google’s search results and from web browsers that use Google’s database of malicious sites. (You can find more information about dealing with Google’s malware warnings in my guide.)

Call for information

To help webmasters protect their websites from this infection we should identify the vulnerabilities used by hackers in this attack. It would be great to hear from webmasters of the compromised sites and from their hosting providers – any additional internal information (e.g. server logs, file permissions, backdoor scripts) is welcome. You can leave your comments here or contact me directly.

P.S. In the next post I’ll talk about the modification of this attack where hackers use intermediary servers to redirect unsuspecting visitors to the same throw-away domains that were generated using Twitter API.

Related posts:

• Intermediaries to Torpig Attack Sites
• Hackers Use Twitter API To Trigger Malicious Scripts
• Revenge of Gumblar Zombies
• Evolution of Hidden Iframes
• All reviewed website hacks