Obviously, no business or personal data was safe; we found logs with business information on shipments, intellectual property, pension funds, legal cases, patients, marketing strategies etc. but also personal information that criminal elements could use to their own benefit.

Following are some of the records that were on that server for grabs.
We changed/blurred information to protect people’s and companies’ privacy.

Medical record:

Email communications:

Outlook with email communications:

Bank customer’s credit card details:

We were especially curious how these user data for grabs were managed by the cybercriminals, and we found a C&C application that they used for that purpose.
The administration of this Command & Control (C&C) function consists of a PHP based web application. It managed the infected machines, and enabled the criminal to address specific groups of “users” –by country, by IP, by type of logs, you name it!

The administrator could also issue commands, instructing the Crimeware on the infected machines to perform certain actions:

The server we investigated hosted multiple “attack campaigns”.
Each campaign had its own logged data from the infected users, as well as an administrative interface to the attack Crimeware toolkit that was used to infect the users (in this case the “AdPack” toolkit).

The administrative (statistics) interface to these AdPack toolkits showed how effective each campaign was, and provided statistical information on the geographical location of the infections, and of course, referral statistics to accurately measure where did the infections come from.

With user data services as described above, we now see that Crimeware has reached a new level of sophistication – again!
We see that Command & Control applications enable administrators to manage the actions and performance of their Crimeware. It gives them also control over the users of the Crimeware as well as its victims. Most scarily of all – it also allows easy access to user data.
The full research is captured in our MPOM April 2008.
We would like to emphasize, that due to restrictions set by law, the research discloses only a fraction of the amount and type of data that we found on the crime server.

Related posts:

1. Crimeware server and the international man of mystery
2. Snooping into Palin emails? Watch out for the criminals snooping on you!
3. Neosploit – The rumors of my demise have been greatly exaggerated

–quote–

On investigating on your complaint , we have determined that the domain name “SPYWARESAFE.NET ” is in violation of the terms of usage of the Privacy Protect service. We have therefore,

1. disabled the Privacy Protect service for the domain name, such that it now displays the putative contact details of the domain name holder, and
2. notified the sponsoring Registrar about the complaint, who shall act upon the complaint in accordance with their policies.

For any further updates on this matter, you can contact ESTDOMAINS, INC.  , the sponsoring Registrar for “SPYWARESAFE.NET”.

We are extremely particular about preventing misuse of our services in any manner. Should you encounter any other such instances, please feel free to notify us immediately.

–quote–

It’s interesting to note how a little exposure, combined with an email pointing out that the privacy protection is in direct violation of the service terms, gets some gears in motion. Don’t expect though to get complete verifiable details on the domain owner… The known issue with whois data is not limited to hideouts such as privacyprotect.org, but to the entire scheme of how domain registration works, and the accountability (or lack of) of the registrars to make sure that the details of domain owners are at least somewhat relevant. As you can see from the below data, trying to find a “Pavel” that lives in Russia, is like trying to find a “Mohammad” in Saudi-Arabia, or a “Mr. Smith” back in the states…

–quote–

Registration Service Provided By: ESTDOMAINS INC
Contact: +1.3027224217
Website: http://www.estdomains.com

Domain Name: SPYWARESAFE.NET

Registrant:
N/A
Pavel        (linkwork@mail.ru)
kremlin st. 1
Moscow
Moskovskaya oblast,123456
RU
Tel. +495.1231212

Creation Date: 05-Dec-2007
Expiration Date: 05-Dec-2008

–quote–

At least the onion is starting to peel off and maybe hopefully law-enforcement can get better details on the owner, or work with the registrar to track him/her down.

Off to Amasterdam now – see you in BlackHat EU (Friday the 28th, track 2, 10am)!

Related posts:

1. Taking down a malicious site – the good, the bad, and the ugly…

Meoryprof.info was the first to buckle (probably under the press exposure), but spywaresafe.net have managed to stay afloat for quite a while. The problem with such domains these days, is that they are usually designed to hide the true owner in the best possible way.

Spywaresafe.net has been running in full-steam for only a short period of time, but has managed to rack up quite a track record of user visits and infections (see the below screenshot from its NeoSploit admin page)

(note that this screenshot is rather old and contains data on the first half of February only… nevertheless, almost 300k visits were logged to the main user and 150k more on the second user)

Looking into the whois record for spywaresafe.net would yield a disappointment – it is hidden using a service provided by privacyprotect.org. This service allows domain owners to hide behind an entity that would provide them “privacy”. The practice itself may seem questionable, but privacyprotect.org has a nice website with easy to access forms for requesting the disclosure of a domain owner in case there is some kind of “abuse” done by it.

Well… that didn’t really work. Sending a couple of these forms in the past month got us absolutely nowhere. No response, not even a decline for our request. These guys must be doing a too good of a job protecting something (definitely not internet users, but something…).

On the bright side, when we contacted the hosting company that was associated with the IP address for spywaresafe.net (78.109.18.130), the response was surprisingly quick, and the security guys there took the offending site down (p.s. – always use email, trying to call in brought an unbridgeable language barrier):

—quote—

…

The actions accepted by us:

Server IP: 78.109.18.130 it is disconnected and formatted.

…

—quote—

Although the company policy there is not to disclose details about the client who paid for this service (can’t blame us for trying ).

Moral of the story – undecided (hence – good, bad, ugly?). Seems like the law enforcement efforts does work, on targeted incidents (no follow up on the second domain). Trying to be the good samaritan does not always play well, and you get to hurdles such as these privacy protection schemes (which in my opinion have no place on the internet), and to surprises such as the guys in hosting.ua (Ukraine’s national hosting) who diligently stepped up to the plate. One has to admit that there really is no place for discrimination on the net…

In hope that we won’t have to do any more of this and have law enforcement and CERTs kick in for those cases, I’ll sign off for this time

Related posts:

1. On the (dis)merits of privacy
2. Taking the Red Pill Down the Rabbit Hole
3. Crimeware server and the international man of mystery

In itself, this is not a new technique, but the sheer size of it made us take a second look (incidentally, another security researcher has gone public with the details at the same time while we were communicating with Google’s security team about it). So how does it work? Basically the recipe is quite simple:

1. Find an XSS vulnerability on a major site that has a decent amount of traffic (easy).
2. Decide what you want your victim to “experience” – this can vary from serving some malicious code, to pure  Crimeware marketing (lessons learned from “what to avoid”  from SPAM email marketing).
3. Start googling it with the XSS in the URL (most sites normally allow parameters to be passed in a GET rather than enforcing POST only).
4. Enjoy the show – make sure that the XSS (usually a search page) also contains some keywords that would attract hits from legitimate searches.

XSSed sites used:

From what we have seen so far – including sites such as torrentreactor.net (first one) and zdnetasia.com (on 3/4/2008), tv.com (2/5/2008), torrentportal.com (3/8/2008), University of Pittsburgh’s jurist.law.pitt.edu, torrentfreak.com and fulldownloads.us (3/9/2008).

Unwanted sites used in the attack:

From is-t-h-e.com, through 72.232.39.252, media-toolbar.com, oasdc.info, do-t-h-e.com – all provide some kind of unwanted malware to be eventually dropped onto the unsuspecting user.

And finally – a glimpse into what people are looking for.  Looking at the keywords used as part of the search terms, we discovered a sort of a zeitgeist of popular terms. The obligatory mature content terms (which I won’t quote for obvious reasons!) to the other extreme such as “the lost book of the new testament bible”, and the more spiritual “working with emotional intelligence” as well as the mundane “chevy tahoe specs”. Even techies are properly served with “bash if or condition”. In short, it provides us with a truly “inspiring” journey into what makes us tick (although we already know, still, seeing it is truly believing).

And now for the replies we got from some affected parties:

From torrentreactor  – who we contacted on 3/4/2008, as their XSS was not public at the time (if you don’t count the outing done by other blogs) – we got a pretty quick response thanking us for the notification, and asking if there were more issues with their site. However, there hasn’t been a fix of the XSS issue yet at the time of this writing).

The more interesting view comes from Google (contacted early 3/4/2008). We contacted them since we saw that some of the search results were sanitized of the offending XSS effect, while other still contained a working XSS.

Google acknowledged that this was a known attack vector, and confirmed that they are indeed working on ways to manipulate and “sanitize” links provided by them in an effort to minimize the effect of incidents such as XSS on indexed sites. They also share our opinion on the reality of XSS and its affects on web browsing: “Google recommends that sites fix their cross-site scripting vulnerabilities as a priority. These can be abused in a number of ways, including bad interactions with search engines. Google is helping by reaching out to affected organizations. In addition, Google has internal processes to block abuses when the situation warrants.”

It will be interesting to see how this will work out  since sites still cache search results, thus allowing search engines to index those as results as well. That practice is exploited here where the site is affected by a XSS, which is then in turn “immortalized” when a search engine sees it.

In the meantime we would recommend the following:

1. Website owners and developers – XSS is rated no. 1 in the OWASP top 10 web application vulnerabilities (no pun intended). Most of them are known. Test for it, fix it. It may not be a direct threat to YOUR site, but it’s a security issue nonetheless and poses a risk to your users.
2. Stop allowing the caching of search results. All the XSS were found in the search pages of the vulnerable sites. Just disable search engine caching for them. There is no added value in it.
3. Search Engines – you have the money and the resources. Although it’s OPP (other people’s problem), you can help prevent and mitigate such incidents (kudos to Google for their ongoing efforts).

Ending on a high note – we stand for security of online browsing, as well as responsible disclosure.

Related posts:

1. Social aspects of web security – the March edition
2. Taking down a malicious site – the good, the bad, and the ugly…
3. Obama Leads in US Presidential Election Poll – the eCrime Way

Obviously, this is a daunting task by itself, and although sometimes security researchers are able to point at specific people as the ones running the criminal activity, it does not always help that much (remember the RBN case where multiple law enforcement agencies were notified, but the people behind the scenes were never arrested or indicted).

Well then, back to our little server – the domain name hosting the crimeware (Neosploit 2.0.13) was hosted in Hong-Kong (see below)

So that does not bring us any closer to who is this – as the address is located at a hosting company. Fortunately, our research brought in some additional IP addresses. We managed to grab these from the web server just like we have uncovered the 8,700 FTP account credentials that the research paper talks about (no exploits or attacks were used to do so – simply thinking outside the box sufficed).

Tracking these down proved to be a nice tour around the globe (long whois info deprecated for clarity):

Putting all these guys on the map results in a very interesting “international man of mystery” cross-continent network of connections:

Obviously we are looking at some eastern-bloc oriented operation, with some access to resources in the Netherlands and the US (either other people, or just computers from which access could have been made).

Now that law enforcement agencies are involved with this, maybe we would see some developments on the matter, although from the looks of these pins on the map, I expect some really interesting multi-lingual cop-speak to spur out soon…

Related posts:

1. Crimeware server catering to “grab and run” criminals
2. Taking down a malicious site – the good, the bad, and the ugly…
3. On the (dis)merits of privacy

We have been watching in amazement the impact our latest Malicious Page of the Month had on the industry and media.
From coverage at Fox Business News, and the Washington Post, all the way to the more “traditional” security outlets such as SecurityFocus, SC Magazine and bloggers such as Dancho Danchev.

The scary thing is the non-media related impact – we are still seeing a tremendous amount of domains (and sites) that are still compromised. Just a quick preview of the ongoing research we are putting into this – we are getting closer to getting to the root (no pun intended) cause of the problem that seems to affect Linux webservers (and this time it may not be a cPanel related issue for a change).

Looking forward to posting an update soon as we make progress in cracking this one.

Related posts:

1. Two steps forward, one step back – controling botnets…
2. Hitting the nail on the head
3. Hosting provider crackdown?

According to a report, the most common malware attack in 2007 is the notorious IFRAME.

On our monthly and quarterly reports we provided more in-depth analysis of such top-ranking IFRAME and obfuscated code.
In Finjan’s terminology, the top-ranked virus IFRAME is not a malware or a virus, it’s more like how criminals are directing users’ browsers to a malware. Interestingly enough – the runner-up is “Mal/ObfJS” – Obfuscated javascript, again no a virus or malware but a simple technique to hide exploits from signature matching inspection.

How come? Well, remember that signature-based solutions are in a dire need to be able to stop the more common techniques employed by attackers (we have actually started to report on them during 2006), since the detection technology is limited in detecting the obfuscation and evasive techniques – typically signaturing the de-obfuscating portions of the script.

This has led to the recent reports of false-positives by multiple AV vendors lately, as active-content is becoming more and more complicated, and the ways to express an action in interpreted code are very complex – meaning that signatures in this realm are almost obsolete (you can see the honorary mention of the “DF” function (Mal/FunDF) in the 10th place, which is a signature on a specific de-obfuscating function – again, no mention of any malicious action taken by it, it’s just that it had it’s 15 minutes of fame when it was used by toolkits to deliver actual malicious code…)

Looking forward to 2008 I really hope that the industry as a whole will not be lagging behind the attack vectors as it did in 2007, and new and improved engines would enable end-users (especially consumers who do not benefit from the more sophisticated solutions offered to enterprises) to have better protection when using the internet.

I know what my new-year resolutions are – do you?

Related posts:

1. Have something to hide? make a lot of noise about it!
2. IFRAME is a security risk???
3. Playing with obfuscators – teaching an old dog new tricks…

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

Related posts:

1. Playing with obfuscators – teaching an old dog new tricks…
2. Hitting the nail on the head
3. Have something to hide? make a lot of noise about it!

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…

Related posts:

1. Have something to hide? make a lot of noise about it!
2. Hitting the nail on the head
3. And the winner for “top virus” of 2007 is…

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

Related posts:

1. And the winner for “top virus” of 2007 is…
2. Tying it all up – explosive exploits…
3. New Orkut worm takes us back in the wayback machine