A Case of Keitaro (featuring RIG and Nuclear)

Introduction

Zscaler ThreatLabZ closely monitors exploit kit activity and we have seen some interesting trends in RIG Exploit Kit behavior recently, including a significant spike in cases observed in the wild. We specifically saw large upticks in the closing weeks of January.

Fig 1 - RIG Blocks over 2 Months

While trying to replicate some of the cases in our testing VMs, we found an infected site suddenly began serving Nuclear EK, and we noticed it doing so via a Keitaro Traffic Distribution System campaign. We have been monitoring these actors since, and in this blog we will briefly describe the activity seen among these campaigns of Keitaro, RIG, and Nuclear.

Keitaro TDS

Traffic Distribution Systems are software and service packages that do pretty much what the name says: their primary function is to intelligently route web traffic that arrives at the TDS operator controlled server. This is not to say they don't have any other functionality, major TDS packages like Keitaro actually provide a great deal of flexibility and control, and malware and exploit kit operators take significant advantage of these features.

In an industry that generally prefers to keep operational and functional details under wraps, Keitaro is an interesting beast that doesn't shy away from the public eye. Keitaro not only has a readily accessible public website with what appears to be a reasonable cost and easy purchase process, there is also a full online help section and an online demo!

Fig. 2 - Keitaro TDS Dashboard

Overview

Keitaro has many features and options, and we don't want to recreate the online help files, so we will only cover some of the basics with few other interesting highlights. This TDS operates on highly-customizable campaigns which come in three flavors: standard redirects, banner serving, and simple impression tracking. These campaigns can have multiple "streams" chosen by linear or randomized selection, and can identify users by IP and/or cookie and enforce unique hits on them across variable timeframes.

Fig 3 - Keitaro TDS Campaign Creation

Besides identifying users by IP and cookies, Keitaro can make decisions based upon a wide variety of features including:
- browser version
- geographic location
- OS/platform
- Mobile carrier

While we can't say which specific rules have been set up by the operators of this instance of Keitaro, we have seen some behaviors mentioned above (especially blocks on repeat attempts from the same source IPs) in addition to the gate serving both RIG and Nuclear at different times.

Observations

So far, we have described a system that seems perfectly above-board, however Keitaro has some features that appear to be designed specifically for bad-actors such as EK operators. One major feature recently highlighted by Kafeine is the addition of AV checks. This feature allows the TDS operator to make sure none of the payloads being served are detected by AV vendors. Conveniently, they integrate with services that don't share samples with the AV industry. Additionally, there is a section in the help files that specifically details how to break referer chains. This is a feature that directly impacts the ability of researchers to trace activity chains and connect exploit kit instances back to the originating site.

Fig 4 - Keitaro TDS Help Information

While Keitaro appears to be very powerful and highly polished product, we spotted some interesting misconfiguration side effects from this campaign. Early on in our monitoring, the TDS would attempt to direct repeat visitors to "www.yahoo.com" using a 302 redirection. It turned out that, lacking the scheme portion of the URL, the redirect ended up sending users to the login page of the Keitaro admin panel. This is illustrated in the screenshot below, where an infected page has two injections for the Keitaro gate. The first injection yields a RIG cycle and the second improperly attempts to redirect to Yahoo.

Fig 5 - Keitaro TDS Redirecting to Admin Panel

Another misconfiguration case we saw may have been an issue more related to the EK infrastructure than on the TDS itself, but one visit to an infected site yielded a redirect to an invalid RIG URL: hxxp://out%2520of%2520datedate/?apitoken=l3SKfPrFJx_ESYjCJunFSrdObkXRFh-BxoubkOM

Despite the occasional misconfigurations seen in this Keitaro instance, it has proven to be a significant source of traffic for both RIG and Nuclear.

Fig 6 - Keitaro Traffic over 30 days

RIG

The RIG Exploit Kit has been very active in recent weeks, and we have identified multiple campaigns with some varying tactics. We've seen a few cases of malvertising and multiple styles of gates including the occasionally misconfigured Keitaro already discussed..

Gates

In recent behavior, we have seen two primary types of gates being used besides Keitaro. The first was the common gate that has been seen in RIG campaigns for some time. The second was a series of gates that followed a pattern of using the same second level domain across four top level domains, rotating the second level names roughly every 24 hours.

Common RIG Gate

We don't have a clever name for this gate, but it's a familiar pattern, with a number of features at malware-traffic-analysis.net. It uses a host naming scheme similar to the infrastructure that actually delivers RIG landing pages and payloads: a two letter third level domain on top of what appear to be domain-shadowed accounts at Godaddy. The URL path in each case is a randomized .php filename with no parameters.

Quad Power Gate

Due to their use of the same second-level name across four TLD's, we are calling this the Quad Power Gate. This gate utilizes the TLDs .win, .top, .party, and .bid. Though the operators of this gate cycled the hostnames frequently, the path used for the gate's URLs has only changed twice. The first hits seen on the Zscaler network were to domain.tld/persil.php, but we later saw domain.tld/deliner.php. Beginning on the 23rd of February, we the gate began using the filenames "magnum.php" and "puerto.php".

Fig 7 - Quad Power Gate Repeatedly Serving RIG

While a casual glance at the content returned by the gate might lead one to believe it's simply serving a jQuery script, the truth is that a RIG iframe is actually hidden between large blocks of Javascript. This gate also turns out to be a repeat offender, not only because we found its presence in a number of infected sites, but the gate has a tendency to repeatedly refresh itself, generating one RIG impression after the other. Although we could not confirm any specific instances, we believe this gate to have been used in malvertising attacks as well.

Landing Pages

RIG landing pages, much like the URL pattern used, has not changed too much. The landing page basically consists of one large blob, with multiple script objects, and several layers of encoding and obfuscation.

Fig 8 - Exceprt from RIG Landing Page

Payloads

Execution is achieved on victim machines via two primary paths: first the usual IE/VBScript God Mode exploit (CVE-2014-6332), and second a large and highly obfuscated Flash payload. Despite the complexity of the protections employed, they are not using the Diffie Hellman-based protection for triggers and shellcode stages. The Flash payload appears to focus on CVE-2015-5122

As for malware, we have recently seen Tofsee being delivered by RIG.

Fig 9 - Strings Decoded from Binary Data in RIG Payload

Nuclear

Like RIG, the Nuclear Exploit Kit is a prolific threat to web surfers. However, it maintains its position in the EK hierarchy, being more sophisticated than RIG yet not quite as cutting-edge as Angler. As an illustration of this point, we have not yet seen Nuclear adopt the latest Silverlight exploit that Angler recently debuted.

Fig 10 - Nuclear Blocks over 2 Months

Gates

Besides the Keitaro gates, we have seen one prolific gate pattern over all else. The operators of this campaign seem to use infected sites which then redirect to the Nuclear landing page. We have seen some very interesting cases of this gate, including one site apparently owned by a bicycle shop in the UK. In this instance, the gate injection was served via the shop's Ebay page, in requests for embedded images.

Fig 11 - Nuclear Gate Inject in Image from Ebay Listing

Landing Pages

Nuclear's landing page continues to utilize data stored in various HTML elements, which is then parsed by scripts to identify browser and plugin features and determine the execution flow.

Fig 12 - Nuclear Landing Page Excerpt

Payloads

Nuclear continues the trend of delivering single file Flash payloads, with multiple secondary payloads: one each for Flash versions <18.0.0.203, <19.0.0.207, and higher. We saw an interesting change between the method used to transition to the secondary payloads.

The initial first-stage SWF used a complicated execution flow with the three payloads being constructed across multiple functions. In each case, two separate arrays of bytes are combined before a version-specific XOR key is used for the "final" payload. We use quotes around "final" because Nuclear continues to utilize a Diffie Hellman protocol to protect the actual exploit trigger and shellcode stage.

Fig 13 - Nuclear Stage 1 Payload Obfuscation

The latter first-stage Flash payload dispensed with all of the complicated reconstruction, and simply uses base64-encoded strings to encode the second-stage SWFs. The second-stage payloads, however, were almost identical to those found in the previous iteration as shown below.

Fig 14 - Nuclear Stage 2 Payload Comparison

The second stage exploits appeared to be CVE-2015-5122 for Flash <18.0.0.203, CVE-2015-7645 for <19.0.0.207, and the "default" case of CVE-2015-8651 for anything newer. Besides the Flash exploits, we also saw CVE-2013-2551 for direct exploitation of IE.

Following succesful exploitation, we have seen Dofoil being installed. The screenshot below shows its signature pattern of decoy GET and POST requests to URLs in the browser history with a few actual callbacks mixed in. The command & control server even uses 404 error codes to attempt to mask the nature of the callback activity.

Fig 15 - Nuclear Cycle Including Dofoil Callback and Decoy Traffic

Conclusion

Though Nuclear and RIG both generate a good deal of impressions via other routes, the Keitaro gate has been a significant source of traffic on its own. It's clear that the flexibility in Keitaro's configuration options make it a powerful partner for the criminal operators of these and other exploit kits. As always, Zscaler ThreatLabZ will continue to monitor Nuclear, RIG, and Keitaro for further developments.

International Council of Women site leading to Nuclear & Kelihos

Introduction

We recently wrote about a compromised Chinese government site leading to an Angler Exploit Kit (EK) infection cycle. Nuclear EK operators are on par with their Angler EK peers in terms of the activity we are seeing in the wild. During our course of EK hunting, we came across a popular multinational organization, the International Council of Women (ICW), being compromised and leading users to a Nuclear EK landing site. The end user will get infected with the information stealing Kelihos bot if the exploit cycle is successful.

Compromised site - ICW

The following screenshot shows the malicious iframe injected on the compromised website.

Compromised ICW web page

 

The malicious iframe leads users to a Nuclear EK landing site as seen below.

Nuclear EK redirection

The Nuclear EK landing page is heavily obfuscated to evade security software detection as shown below.

Nuclear EK landing page

Upon successful execution of the obfuscated JavaScript, a malicious Flash file is downloaded on the victim's machine as seen below.

Flash Exploit Download

Kelihos Payload Analysis

Upon successful exploitation, a new variant of the Kelihos bot is downloaded and installed on the victim machine. Here are some of the download locations for the Kelihos bot that we have seen in this campaign:

 hxxp://46.63.32[.]75/harsh02.exe
 hxxp://95.65.55[.]6/harsh02.exe        
 hxxp://31.202.178[.]239/harsh02.exe    
 hxxp://37.233.40[.]97/harsh02.exe    
 hxxp://178.136.213[.]107/harsh02.exe

Final Payload Download

Kelihos is a Trojan family that distributes spam email messages. The malware communicates with remote servers to exchange information that is used to execute various tasks, including sending spam email, capturing sensitive information or downloading and executing arbitrary files.

The malware executable file is a Microsoft Visual C++ 6.0 compiled binary with custom packed content stored in the executable's overlay section. Kelihos installs WinPcap, a legitimate and commonly used Windows packet capture library at the following locations:

• %system32%\winpcap.dll
• %system32%\Packet.dll
• %system32%\drivers\npf.sys

Note: %system32% is c:\windows\system32

It uses hard coded User-Agents from the following list when communicating with the remote host:

Crafted User-Agent

Kelihos tries to steal the login credentials of FTP and POP3 applications by monitoring the network traffic of the victim's machine using the installed WinPcap libraries. The bot checks for the presence of the following applications on the victim machine and attempts to steal login credentials, digital currency and other information:

• 3D-FTP
• Bitcoin
• BitKinex
• BlazeFtp
• Bullet Proof FTP
• Classic FTP
• Core FTP
• CuteFTP
• Cyberduck
• Directory Opus
• FFFTP
• FileZilla
• Frigate3
• FTPGetter
• LeapFTP
• FTPRush
• xterm
• PuTTY
• SecureFX
• SmartFTP
• Bitcoin
• BitKinex

The malware extracts stored information such as usernames, passwords and host names from the following browsers:

• Google\Chrome
• Chromium
• ChromePlus
• Bromium
• Nichrome
• Comodo
• RockMelt
• CoolNovo
• MapleStudio\ChromePlus
• Yandex

Kelihos communicates to Command & Control (C&C) servers using HTTP via messages encrypted using the Blowfish symmetric-key algorithm.

Post Infection Communication

Conclusion

Nuclear EK remains a worthy rival to Angler EK, with widespread campaigns, regular exploit payload updates, new obfuscation techniques and new malware payloads. The end malware payload we saw in this campaign was the information stealing Kelihos bot which has extremely low AV detection.

ThreatLabZ is actively monitoring new Nuclear EK infections in the wild and ensuring that Zscaler customers are protected.

Research by Dhanalakshmi PK and Rubin Azad

Exploit Kits: Anatomy of a Silverlight exploit

With the significant adoption of Silverlight technology in today’s market, it has become one of the popular targets for the hacker community. We have observed many popular exploit kits (EKs) like Nuclear and Fiesta, serving specially crafted exploits targeting Silverlight vulnerabilities. Recently, we blogged about the Nuclear Exploit kit live infection cycle, which was leveraging Silverlight vulnerabilities to infect the victim’s computer. In this blog, we will take a look at the Silverlight exploit payloads and how they are embedded in the Exploit kit.

A Silverlight file is a zip archive with an ".xap" extension and it is written in the .NET language. This XAP file contains a list of one or more .NET managed assemblies (.DLL files) along with the AppManifest.XAML file.

We have observed that Exploit kits are generally targeting following Silverlight vulnerabilities:

• CVE-2013-0074: Memory Dereference Arbitrary Code Execution Vulnerability.
  This vulnerability is due to an improper boundary checking of the user supplied input which leads to arbitrary code execution.

• CVE-2013-3896: Information (memory) disclosure Vulnerability
  By exploiting this vulnerability an unauthorized attacker can gain access to the sensitive information. This bug is used to bypass the exploit mitigation technologies.
  
  
  The following is a typical infection cycle involving Silverlight exploits in EKs:

Dissection of the Infection Cycle and Silverlight Exploit:

As we discussed in our previous blog, the landing page of the Nuclear Exploit kit is heavily obfuscated to evade Anti-virus detection. The function highlighted below is invoking the Silverlight exploit:

As we stepped through the deobfuscated code, we found that the exploit author has implemented multiple unused variables to possibly confuse analysts. We saw a parameter named “tuti” which contains the base64 encoded data that decodes the shellcode.

Upon successful execution of the silver_run() function, the Exploit kit will download a malicious XAP file with the following GET request.

The downloaded XAP exploit consists of three files as shown below.

The AppManifest.xaml file contains the deployment details needed to run the Silverlight application. The first element of it starts with a deployment node which defines the Assembly information, Runtime version, Application Entry point and the assembly extension parts. In this file, There is an attribute called 'RuntimeVersion' through which we can target a specific version of Silverlight. There are two other important attributes, namely EntryPointAssembly & EntryPointType which are mainly used for loading the XAP file.

Reverse engineering the .NET DLL file is straightforward, because it is MSIL (Microsoft Intermediate Language) and there are multiple tools at our disposal. We used the Telerik JustDecompile tool to decompile the DLL. The following screenshot shows us the list of the classes used by the asdgsd.dll.

The screenshot below shows the entry point routine asdgsd.App. The constructor of asdgsd.App is used to call the shlyapa class.

The following activity is performed by the shlyapa class which attempts to exploit multiple silverlight vulnerabilities:

• Get the .NET run time environment version and store it in the “mild” variable.
• Get the base64 encoded stream from aforementioned “tuti” parameter and store it in “brae” variable and invoke the "dips" function.
• In parallel, the function “lout” generates the “numArray” leveraging  class “chaiki”.
  

  

•     Function "lout" generates the "BitmapImage" instance by calling function "game" from "alupka" 

• The function "huts" is leveraging CVE 2013-3896 (A memory disclosure vulnerability in the public WritableBitMap class) to calculate the base-address of "mscorlib.ni.dll" as seen below:

        

• Finally, the "dips" function executes the "spca" function that takes the base-address of "mscorlib.ni.dll" as an argument. The "spca" function is triggering CVE-2013-0074 (Dereference Vulnerability during HTML object rendering) as shown below:

The following is a sample of live Nuclear Exploit Kit domains that we have seen in past 24 hours:

Nuclear EK Domains 

indyresident[.]gq

macropromise[.]ml

hybridvertex[.]gq

macropromise[.]ga

uthunilaej[.]co[.]vu

daviddaniel[.]cf

brightrolling[.]ml

culturemerge[.]ga

Conclusion:

We continue to see the Silverlight vulnerabilities mentioned in this blog being exploited by many other popular exploit kits. Zscaler is actively monitoring and protecting end users against this threat.

Credit for Analysis & Guidance : Dhruval Gandhi

Nuclear exploit kit - complete infection cycle

Zscaler ThreatLabZ has been seeing a steady increase in the Nuclear Exploit Kit (EK) traffic over the past few weeks. The detection of malicious activity performed by this EK remains low, due to usage of dynamic content and heavy obfuscation. In this blog, we will walk you through a complete Nuclear EK infection cycle with a live example. We will also share details of the identified payload, which had very low Anti-Virus (AV) detection rates.

The infection cycle begins with an unsuspecting user visiting a legitimate site that was compromised by the attackers. The compromised site in the example covered in this blog is www[.]cornwallmusiceducationhub[.]org that further redirects the victim to the Exploit Kit hosting server [80.85.86.133]. Nuclear EK is notorious for exploiting most popular browser plugins.

The following screenshot shows the malicious iframe injected on the compromised website.

Malicious iframe in compromised domain

The malicious iframe leads the users to a loading site, which in this case performs a second level redirection as shown below, eventually leading the victim to the Nuclear EK's landing page.

Redirecting to the Nuclear EK landing page

Redirection Chain observed in our example:
Compromised site : www[.]cornwallmusiceducationhub[.]org/tag/heartlands-pool/
Second level redirection site: fluersutel[.]tecnopes[.]com[.]ar/miksopulp16[.]html
EK Landing site: actudismatik[.]e-xms[.]com[.]ar/2150b060shv/1/9ffbf35e4190fbba62f70c8477fa3964[.]html

Redirection Chain

The Exploit kit landing page is heavily obfuscated to evade detection by AV and Intrusion Prevention Systems as seen below:

Landing Page

Now we will step through the complete dobfuscation of the landing page that was captured in above example. We leveraged the open source JavaScript beautifier to structure the landing page JavaScript code. Upon structuring the code, we determined that there were 51 unused variable declarations to confuse the researchers.

Going further, we observed that the following three functions VV8Y6W,wL3, and Fp4Ovo were responsible for the dynamic de-obfuscation of the EK landing page code. We have noted the action performed by each function in the following screenshot.


The following routine leverages the aforementioned functions to generate a key PluginDetect (V 0.8.8) script which we will discuss later. 

Upon successful execution of the above code, the variable KKa will store the PluginDetect script. The following code will execute the script.

PluginDetect

This script is derived from the well-known JavaScript library PluginDetect. This library is used by the exploit kit authors to do a detailed reconnaissance of victim's browser plugins. We will walk you through various actions performed by this script before executing the exploit payload.

First the detectPlatform function will check for the operating system running on the victim machine:


Subsequently, the script will also check the version of well-known browser plugins, which includes Java, Adobe Reader, Adobe Flash, and Silverlight. 


It then leverages the XML DOM information leakage vulnerability to enumerate through the system driver files residing in the C:\Windows\System32\drivers\ directory. If it finds any AV driver files, the script will terminate the infection cycle.

Next, the script will check for the vulnerable versions of the loaded plugins and accordingly run the identified application exploit function.

The following screenshot shows the application specific exploit functions:

Below are the exploit payloads that were getting served if the related application plugin version was found to be vulnerable by the Nuclear EK instance that we analyzed. AV detection for the payloads delivered by this variant remained poor at the time of blog publication.

Silverlight Exploit:
CVE:2013-0074
actudismatik[.]e-xms[.]com[.]ar/2959962158/2/1410771180[.]xap
MD5: 94ef35e1ecf0a486ab790957ad794a85
Size: 9139
VT: 2/55
Flash Exploit:
CVE:2014-0515
http://actudismatik[.]e-xms[.]com[.]ar/2959962158/2/1410771180[.]swf
MD5: da5d57c700ebec211a6a57166700e796
Size: 5832
VT: 1/55
PDF Exploit:
http://actudismatik[.]e-xms[.]com[.]ar/2959962158/2/1410771180[.]pdf
MD5: 3676bf357f0678a609df6831b7a870a0
Size: 9769
VT: 1/54

If the exploit attempt is successful, then the EK code will silently download and install the following malware payload on the victim machine.

Malware:
http://actudismatik[.]e-xms[.]com[.]ar/f/2/1410771180/2959962158/7
MD5:acd0fe0c2ce27b8b9fa8741e23e39b81
Size:319488
VT:4/55

Dhruval

Nuclear Exploit Kit and Flash CVE-2014-0515

For this blog, we'd like to walk you through a recent attack involving Nuclear Exploit Kit (EK) that we analyzed. It was found leveraging CVE-2014-0515, a buffer overflow in Adobe Flash Player discovered in April 2014.

Nuclear Exploit kit targets a number of known vulnerabilities including:

• pdf - PDF:Exploit.PDF-JS
• swf - CVE-2014-0515
• jar  - CVE-2012-0507

Below are the files which were downloaded during the exploitation attempts observed:

FILE TYPE	MD5	SIZE	CVE/THREAT	VT HITS
FLASH	A1465ECE32FA3106AA88FD666EBF8C78	5614	CVE-2014-0515	18 / 53
JAR	A93F603A95282B80D8AFD3F23C4D4889	12396	CVE-2012-0507	26 / 54
PDF	19ED55EF17A49451D8052D0B51C66239	9770	Exploit.PDF-JS	22 / 54
EXE	8BCE8A59F9E789BEFB9D178C9A03FB66	104960	Win32/Zemot	39 / 53

Although there are other associated vulnerabilities that are being exploited by Nuclear Exploit kit, we will limit this blog post to reviewing the Flash exploitation (CVE-2014-0515).

Nuclear EK Landing

Unlike other EKs such as RIG, Nuclear EK's landing page code is highly obfuscated.

(Fig 1: Obfuscated Landing Page)

After de-obfuscation, the page looks as follows:

(Fig 2: De-Obfuscated Landing Page)

Nuclear EK's landing page checks for the following antivirus (AV) driver files and if finds any, terminates the exploitation process. We have seen these checks before in RIG EK too.

(Fig 3: Check for AV driver files)

If this AV check is passed, a javascript function then checks the installed Flash version and if a vulnerable version is detected on the client's browser, a call is then made to a dynamic Flash object creation module.

(Fig 4: Flash Call)

Here are the vulnerable Flash player checks:

(Fig 5: Checks if vulnerable version installed)

If the version check passes, the Flash exploitation process will commence as seen below.

CVE-2014-0515 exploit analysis

Here is the code that dynamically creates a new Flash Object:

(Fig 6: Flash Object Creation)

The Flash exploit payload that gets downloaded is highly obfuscated to evade AV detection. Below is a snippet of decompiled code from this Flash exploit:

(Fig 7: Decompiled Flash File)

There are two hard coded snippets of obfuscated shellcode in the action script as seen below:

(Fig x1,x2: Raw Shellcodes)

 

After de-obfuscating on the run time, it adds bytecode to a Shader Object from one of the de-obfuscated shell code snippets.

    (Fig 8: Shader Byte Code Filler)

The Shader's Pixel Bender is where this malformed byte code is written, which triggers the vulnerability.

Here is the Malformed byte code:

(Fig 9: Malformed data for Pixel Shader)

Disassembling Pixel Bender's byte code

We used Tinc Uro's program to get the PixelBender binary data decompiled.

(Fig 10: Decompiled PixelBender data)

We can see the inappropriate content here. The Shader Object takes a float parameter whose default value is set to a matrix of 4x4 floats and the second float value of this matrix is invalid value triggering the vulnerability.

Conclusion

Since the downfall of the popular Blackhole Exploit Kit, we have seen the advent of many new Exploit Kits. Nuclear Exploit Kit definitely ranks in the Top 5 prevalent EKs in the wild at the moment. We have seen an increasing number of compromised sites and scam pages leading to Nuclear Exploit Kit in past three months. Some of the notable compromised sites during this time frame that were redirecting to Nuclear EK includes:

SocialBlade.com - A youtube statistics tracking site.
AskMen.com - Men's entertainment website
Facebook.com survey scam pages

Exploit kits generally make use of known vulnerabilities and Flash is a popular target. CVE-2014-0515 in particular targets a Flash vulnerability in Flash versions before 11.7.700.279 and 11.8.x through 13.0.x before 13.0.0.206 on Windows and OS X, and before 11.2.202.356 on Linux. It's critical to ensure that your employees aren't running outdated versions of Flash as it is commonly targeted by EKs.


References:

• http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/
• http://www.semantiscope.com/research/BHDC2010/BHDC-2010-Paper.pdf
• http://www.kaourantin.net/2008/09/pixel-bender-pbj-files.html
• http://www.free-decompiler.com/flash/download.html
• http://malware-traffic-analysis.net/

- Rubin Azad