A few months ago the RIG exploit kit took quite a hit when its source code was leaked by a disgruntled reseller. At the time we wrote a blog post detailing the inner workings of RIG’s infrastructure and business model, comprised mainly of three layers: administration server, VDS and PROXY servers. The first layer is the backend that includes the control panel and the payloads – this is the most privately kept layer, and access is provided only to customers. The second layer is the VDS, which contain the exploits and functions as a tunnel between the first and the third layer, allowing the exploitation stats to be updated in the DB of the administration server. The third and final layer is the PROXY layer, which contains many web servers that are typically only valid for a short period of time each, and manage the interactions between the victims and the upper servers. These are the servers that serve the exploits directly to the victims.
Since the leak incident it seems that RIG author has been hard at work creating a new version of the RIG exploit kit – RIG 3.0. A lot of the concepts remain the same as RIG 2.0 – but within that same environment several changes were made, this blog post will look at some statistics related to RIG 3.0 as well as cover the abovementioned changes.
Statistics :
One of things we were curious about with RIG 3.0 is how well it recovered from the leak. In order to answer this question we had to examine the statistics of RIG 3.0 and see how well it’s been doing :
The screenshots above, taken from the two RIG instances we observed, show the up-to-date state of RIG. It is evident from this overview that not only did RIG 3.0 manage to maintain the exploitation percentage of RIG 2.0, it also managed to vastly increase its number of hits- reaching the high volume of over 3.5 million hits recorded thus far in both instances combined. “hits” is RIG’s term for impressions- the number of times the RIG landing page was sent to a victim. These two instances attempted to infect 3.5 million machines and succeeded in infecting 1.25 million machines, meaning on average 27,000 infected machines per day!
One of the reasons for the high infection rate is attributed to Adobe Flash exploits (as can be seen in the stats above). Throughout the past months there was an abundance of Adobe Flash vulnerabilities, some of which has been a result of reverse engineering patches and others are direct result of the Hacking Team leak, which included Adobe Flash zero day exploits (CVE-2015-5119, CVE-2015-5122).
Payloads :
The next thing we wanted to know was what happens to exploited victims’ machines, once infected. Generally speaking, RIG 3.0 customers deliver various payloads through RIG, each depending on a specific customer, but the distinct top payload delivered here is the Tofsee spam bot, single-handedly representing 70% of all infections. A single customer distributes this spam bot, who also happens to be the biggest customer for RIG 3.0. Let’s call him customer X.
In order to understand the estimated revenue of customer X when delivering his payload through RIG, we’ll take a closer look at its profitability during a one-month period.
Let’s start with the facts: Customer X manages to infect about 500,000 machines per month with the Tofsee payload. The going rate for spam campaigns is approximately 0.5 USD per 1,000 successfully sent emails. This particular payload of Tofsee was observed in our labs attempting to send approximately 1 million emails per day from a single bot, of which about 2,000 emails were successfully sent. These are the raw numbers that were observed. Now let’s try and estimate the actual revenue for customer X per month.
After working for a whole day and successfully sending 2,000 spam emails, odds are that this bot’s IP will be now blacklisted and this blacklist will be shared across the security industry. So we assume that this bot won’t send any more spam for the coming 1-2 weeks. However, we should also note that many of these bots only live for about a week, as computers get cleaned up. For example in some countries you will even receive a notification from your ISP telling you that your PC is infected and you should address that immediately. Thus in order to stay on the conservative side we will assume that after a day’s worth of spam emails each bot will no longer provide benefit for customer X, at least not in the sense of sending spam (he might resell this bot, or install some kind of ransomware on this PC in order to try and maximize profitability per bot – but this is out of the scope for our spam calculations).
So is customer X making 500,000 USD per month? No, probably not. Additional factors to consider are: some of these infected machines were already pre-infected with other kinds of malware, and thus could be either already blacklisted. Alternatively, some machines may simply be unusable due to various security measures deployed (Firewalls, Anti-Virus, Secure Web Gateways, etc…). Based on our observations the more realistic number of bots actually successfully delivering these spam message would be somewhere around 200,000 bots. The last couple of things to consider are (a) the demand for spam isn’t high enough to generate 200,000 USD of income for customer X, and (b) we need to account for the various expenses customer X has to incur (exploit kit rental, traffic for the exploit kit, bullet proof hosting, Tofsee license). Eventually we end up with a realistic, yet somewhat conservative, estimate of revenue: 60,000 USD – 100,000 USD.
Taking the average of 80,000 USD is not too shabby by all counts, right? That is, if you don’t mind being a criminal.
Traffic Sources :
The final question we asked ourselves was “where is all this traffic coming from?” 70,000 hits per day is a lot of traffic, especially when talking about traffic into an exploit kit…
Our investigation shows that 90% of the traffic flowing into the various campaigns of the RIG exploit kit were a result of Malvertisements (malicious ads). Apparently, according to the referers, many large websites were abused by malvertising campaigns in order to redirect visitors to the RIG exploit kit, these include large news sites, investment consulting firms, IT solution provides, etc. all ranked in Alexa’s top 3000. Even though none of these sites worked directly with the advertising networks used to redirect to RIG, because of the way that advertisements bidding works, when a large legitimate advertising network doesn’t have a high-end advertisement to display, it turns to affiliates who offer ads for lower prices, in these low price ranges exploit kits such as RIG can find hits for fairly low prices. To put it simply, these large websites did nothing wrong, much like the infected users they are victims of this malware distribution industry.
So how does a large and popular website end up delivering RIG to its visitors?
Large website Y closes a deal with ad network N, the ad network will display ads on Y’s website, to each of its visitors. Behind the scenes, what happens is that for each visit the ad network will try and process various properties of the visiting user and generate some sort of profile. This profile may include the visitor’s geo-location, gender, age, etc.
Once a profile has been determined a bidding process starts in real-time: the ad company tries to match ads that target predefined profiles and out of all the matching ad providers, the highest bidding provider wins and their ad is displayed to the visitor.
Ad providers are usually smaller ad networks, and these may try and resell the bid further down the chain. Criminals will seek out the cheapest ad providers where they can place their malicious ads and turn that cheap traffic into infections using exploit kits. For the criminal- these infections are their profit so it makes sense, financially, to go to the lowest ad providers down the chain.
Now back to website Y. As we mentioned, it will display ads to all users- some of which have such profiles that doesn’t match any high-end bidders. Naturally, large websites have less visitors with these profiles, but like every other site, these visitors do exist and this small slice of traffic to website Y is where RIG’s malicious ads may get lucky.
It is important to note that both website Y and advertising company N are victims in this story, as they do not control neither the displayed ads nor the low-end ad providers.
In the case of RIG, we’ve noticed at least one particularly popular advertiser called buy-targeted-traffic.com which was used as part of a malvertising campaign by one of RIG’s customers. These campaigns, much like legitimate ones, can be configured to, for example, only deliver hits from users using specific browsers:
For an exploit kit like RIG, which only targets users of Internet Explorer to begin with, this feature helps save money on the campaigns and filter out “uninteresting” traffic from other browsers that will not be exploited anyway.
On buy-targeted-traffic.com a RIG customer can buy 1,000 ad impressions for the low price of 20 cents. Most of these will be on low-end sites, but due to the bidding process described above it may occasionally find itself on a large, popular site.
Due to how RIG saves its data, we can’t know for sure which sites were displaying these ads by buy-targeted-traffic.com.
It is important to note that buy-targeted-traffic.com is a victim of malvertisement.
Infrastructure :
As we mentioned earlier a lot of the infrastructure in RIG 3.0 remained the same as its predecessor, but there is something to be said for how effective this infrastructure is:
The middle layer of RIG, the VDS, remained on the same IP as RIG 2.0 meaning that throughout this entire time and despite the source code leak, the use of a PROXY layer to distance more valuable parts of the exploit kit have paid off- the VDS server, which holds all of the exploits used by RIG 3.0, remained intact and mostly unnoticed, with a mere 1 detection as malicious on VirusTotal:
Another notable change to the infrastructure attests to a change of approach by the RIG author- RIG 3.0 uses only a single VDS server, the reselling model appears to be a thing of the past for RIG, or if it’s still being used, it is certainly kept separate from the RIG infrastructure itself. Though we can’t know for sure what the reason for this change is, it seems reasonable that this decision was at least partly motivated by the fact that a reseller was the cause for the RIG 2.0 leak.
URL Generation :
Another change to the infrastructure of RIG, albeit not a technologically sophisticated one, is a change to the URL pattern of RIG.
In RIG 2.0 the URL format was as follows :
hxxp : //[PROXY_URL]/[proxy.php]? PHPSSESID=[encrypted token]
Since the URL format of the landing page was constant and unique, it was fairly simple for any security product to identify the URL pattern as part of the RIG exploit kit without risk of false positives.
In RIG 3.0 the argument “PHPSSESID” used in the URL was replaced with a new randomized token. We won’t dig into the exact way in which the key is generated, but it is the result of some calculations factoring in real data and a randomized value, meaning RIG can validate its own keys, but it is somewhat more complex for an outsider to identify it as a RIG URL.
Some Security Updates :
Following the source code leak of RIG 2.0, the RIG author had to patch up the vulnerabilities that allowed a reseller with limited access to steal (and proceed to leak) the RIG source code.
Two major changes were made in that regard:
- Prevention of unauthenticated users from accessing internal files hosted on the backend server:
This was a fairly simple fix, it consisted of adding the following line to every internal PHP file that is part of RIG:
include_once($cfg[‘realpath’].’/gears/auth/auth_init.php’);
- Storing of all payload files in the database:
In RIG 2.0 the payloads were stored in a folder on the server, if one was to somehow gain access to the path in which the payloads are stored, any user with permissions to upload a payload could potentially upload a backdoor to the RIG server. Storing all the payloads as data blobs in the database means that these files can only be accessed through RIG’s interface, which prevents execution of these files on the server.
One more security measure we noticed is mitigation to solve an issue the RIG author had with DDOS attacks. In the past several months the RIG 3.0 control panel has been under attack, RIG’s solution to this issue is, like many legitimate sites, protecting the server with Cloudflare.
GUI Modifications :
Last but not least, the above changes are all helpful to RIG, but customers paying for a new version of RIG also need to feel that they’re getting their money’s worth- RIG 3.0 is equipped with a shiny new dashboard layout:
It seems that exploit kits, much like the mythological hydra, just keep coming back. Chopping off one head merely grows two new ones to replace it. They are growing more accurate, more sophisticated, and worst of all, more widespread.
Customers of Trustwave SWG are protected against the RIG 3.0 exploit kit out of the box, as we continue to monitor the exploit kit landscape closely and respond immediately to any changes and developments.[su_box title=”About Trustwave” style=”noise” box_color=”#336588″]
Trustwave helps businesses fight cybercrime, protect data and reduce security risk. With cloud and managed security services, integrated technologies and a team of security experts, ethical hackers and researchers, Trustwave enables businesses to transform the way they manage their information security and compliance programs. More than 2.7 million businesses are enrolled in the Trustwave TrustKeeper® cloud platform, through which Trustwave delivers automated, efficient and cost-effective data protection, risk management and threat intelligence. Trustwave is a privately held company, headquartered in Chicago, with customers in 96 countries.[/su_box]
