Magnitude Exploit Kit Backend Infrastructure Insight - Part II

Welcome back to another edition of "exposing Magnitude exploit-kit internals"! As already mentioned in our previous posts (1^st and 2^nd), the back-end infrastructure of this highly prevalent Exploit Kit has been revealed to be pretty exciting from the security research point-of-view. With this post, we'll expose additional features and cool tricks that Magnitude uses, reveal more information about its infrastructure and talk about its implementation in the wild.

Here is the Magnitude exploit kit Infrastructure schema:

You will notice that the Magnitude Infrastructure can be generally divided into three different roles:

• Gateway Servers – Those instances serve as the first access point of redirected victims' traffic. The Magnitude gateway performs initial validation of victims (which we'll explain later) and redirects to an active Malware Distribution server.
• Malware Distribution (MD) Server – Those servers perform further validation of the redirected traffic, then serve the Magnitude landing page followed by exploits and malicious payloads that are distributed to the victims' machines after exploitation.
• A Management Panel– This single instance is used by Magnitude customers in order to configure and control their malicious campaigns (e.g., upload payloads, view statistics and more). This panel was reviewed in detail at the 1^st Magnitude blog.

This blog post is dedicated to the Magnitude Gateway server, its features and its operation. In order to get a better hold of this information, let's examine the process of creating a new malicious campaign:

Configuring and Launching a Campaign:

First, a cybercriminal wishing to use Magnitude must decide how to redirect traffic to the exploit kit.

Magnitude provides two options:

• Redirect traffic to the Gateway Servers – This option allows filtering traffic based on several pre-provided and configurable filters, such as: geo-location, HTTP referrers, language etc. Magnitude Gateway also provides deeper and more extended verification on each redirected victim (detailed below). Traffic that passes the gateway filters is redirected to the Magnitude MD server to be exploited.
• Redirect traffic straight to Magnitude MD server – With this option the traffic is redirected directly to the MD server. The customer can get the most up-to-date MD server URL using an API which is provided in the Magnitude Management Panel. This option is compelling for cybercriminals who prefer filtering their traffic by some other 3^rd party solutions such as TDS (Traffic Distribution System) servers and then redirect it directly to those servers.

Cybercriminals wishing to redirect traffic through the gateway servers can request a domain from the Magnitude support team and the team will register the domain for them. This domain will be used as a destination for the redirected traffic and will point to the gateway servers. Remember, Magnitude's financial model is based on customers "paying" with web traffic. The Magnitude admins infect about 20% of the exploitable traffic with their own malware – all of that and more is discussed in our previous blog.

Most of the domain names used by Magnitude customers look very similar to legit sites, most of them are low profile. For example: "exemple.com" will be chosen as it looks similar to the legit site "example.com". The cybercriminals can control and edit this site and how it acts in the Magnitude Management Panel. This panel uses the Russian language. Below is an English translation.

Figure 2. New Magnitude Gateway domain configuration

Magnitude customers can enable and disable the domain. If it is disabled, they can configure whether to serve a fake page for that domain, redirect that traffic to a certain URL or return an error.

The Initial Infection Phase

Now let's see how the Gateway server is being used as a part of the infection flow:

Note: The typo in the domain name is intentional.

Magnitude customers use methods such as malvertisment, traffic brokers or compromised sites to redirect victims to the gateway servers.

Magnitude gateway servers check their internal database for the domain configuration including whether it's enabled or disabled, and the filtering parameters with each request they receive. Next, the gateway filters out requests from security vendors and law enforcement agencies based on their source IP:

• The code searches the "banlist" database table for the victim's source IP address. This table contains about 1,400 IP range records belonging to several high profile companies such as Google and Microsoft and security vendors such as Symantec, McAfee, Team-Cymru, Trendmicro and also law enforcement agencies such as the Department of Homeland Security.
• The banbyhostname() function receives the victims' hostname as a parameter by using the PHP's native function "gethostbyaddr." Banbyhostname() searches for the presence of the following words in the victim's hostname: "whois", "proxy", "yahoo", "opera", ".mil", ".gov", "google", "demon", "localhost", "dedicated", "hosting", "leaseweb", "cisco" and "bot". This is another method to evade detection by security vendors / law enforcement agencies / internet crawlers.
• You may notice that strangely Magnitude doesn't filter requests from Australia regardless of their IP or hostname. The reason behind that logic is unclear. Australia probably is a good monetizing source for the exploit kit admin and perhaps the first two filters above caused too many 'false positives' with requests originating from Australia.

The next step conducted by the Gateway servers uses the checkcountry() function in order to filter out requests from forbidden countries list:

If the requests originates from one of the forbidden countries, checkcountry() returns true, $redir will be set to zero, instructing the Gateway NOT to redirect that victim to the MD server. The concept and reasons for not accepting victim's traffic from former USSR countries, small countries from Asia, the Middle East, Africa and South America were presented in our first blog post on Magnitude.

The Magnitude Gateway will continue to perform additional filtering, this time based on the HTTP headers:

First, this code filters out requests made by Internet Explorer 6 on Windows XP, possibly because this User-Agent is commonly used by many security vendors and crawlers. Then, this code filters out requests from web crawlers, specifically if 'google' or 'bot' appear in the User-Agent text. Finally, the Gateway filters web traffic with HTTP headers commonly used by web proxies.

The last filtering phase uses the settings that the cybercriminal configured in the Management Panel: such as allowed countries, HTTP referers or languages.

The Gateway servers are also responsible for collecting statistics per domain and they are provided in the Management Panel. Detailed description of these statistics is provided in our first blog.

FINALLY, victims that passed all the above filters ($redir = 1) will be redirected to the Magnitude MD server:

This code uses the domaincrypt() function. There are several observations about the logic behind Magnitude MD server URL structure that can be learned by analyzing this function.

Magnitude URL Structure Logic

If you ever monitored or analyzed Magnitude infections you must have scratched your head wondering what that long subdomain value before the domain name is and what it represents. If not, here are some examples of Magnitude MD server URLs that were used for infecting victims in the past:

• e504.01c4.a8022.1c.190.ed2e62b.575.808f.hyixoangcqh.cassetteterms.eu
• 241020.2dba.6d01312.011.a85.6b4.d4.df92.cftbmxjli.folksbuilt.in
• 751.895a24.1c7872.05a3.4d.2dafca.a1e.c2.qgzocpal.sliptried.in
• e2f.18.bc5.465f.90.33c10.26.1e098.26.efee.motbypqfa.afternoonride.pw

Recall the Magnitude Gateway redirection code aforementioned:

The implementation of the domaincrypt() function looks as follows:

The domaincrypt() function gets an MD5 value of the concatenation of two strings:

• $site – This variable is a unique numeric value that represents the Magnitude customer ID. Its value is always between 1 and 75. This ID value is retrieved from the Gateway server internal database for each victim's request. The customer ID value is associated with the current domain. That's how Magnitude Gateway knows whom to credit for each redirected victim.
• $redirdomain – contains a short random string concatenated with the current MD server domain name. This value is retrieved from the Gateway server internal database and is updated every minute by a Cron job. For the examples above the $redirdomain is:
  • hyixoangcqh.cassetteterms.eu
  • cftbmxjli.folksbuilt.in
  • qgzocpal.sliptried.in
  • motbypqfa.afternoonride.pw

domaincrypt() function simply splits the hash value into short parts, between 5 and 16 parts, and adds dots between them. That becomes the first part of the MD server URL. That's how the Magnitude admin can retrieve the customer ID from the URL. For example, let's take one of the URLs above and see how to extract the Magnitude customer ID:

e504.01c4.a8022.1c.190.ed2e62b.575.808f.hyixoangcqh.cassetteterms.eu

• Construct the hash from the first part: e50401c4a80221c190ed2e62b575808f
• Compute the MD5 hashes of concatenations of any integer between 1 to 75 with the second part of the URL (hyixoangcqh.cassetteterms.eu). The integer that produces the hash above is the customer ID.

The following simple script can be used to retrieve the customer ID:

Because MD5(23hyixoangcqh.cassetteterms.eu) = e50401c4a80221c190ed2e62b575808. The script's output is:

Using the algorithm above allows you to retrieve the campaign manager ID from Magnitude URLs. That's exactly what the Magnitude MD servers do.

Magnitude Gateway Fake Sites Mechanism

You may recall that one of the options that cybercriminals have when configuring a new Magnitude campaign is to serve a fake site. We were a bit curious why Magnitude customers need this option and how it works.

Figure 9. Magnitude Gateway fake page flow

The purpose of the fake site option is to cause Magnitude Gateway URLs to appear as innocent sites without trying to exploit the client. This solution comes handy when Magnitude clients use traffic brokers or legitimate advertisement services as their main traffic source. The fake site' mechanism can be configured by customers in the Magnitude Management Panel using the "Fake:" textbox:

When the URL is disabled (the 'Active' checkbox is unchecked) and the 'Fake:' textbox is filled, the malicious exemple.com URL, which points to Magnitude Gateway, will fully mimic the legitimate example.com site, including all content such as HTML and JS code as well as images and styles. It will even return the exact same server HTTP Headers as the legitimate site.

How does this solution actually work? When the fake site mechanism is activated, the Magnitude Gateway runs the following code:

This code runs for every request made. First, the $host variable contains the current Gateway URL, e.g. exemple.com. A new directory with full permissions is created for each URL. The $url variable contains the URL of the legit site with the URI of current request. For example, when a victim accesses http://www.exemple.com/page.html the $url variable will be http://www.example.com/page.html. The http_class object is used to send a web request to the legit site and parse the response and the headers. The $md5cache is the MD5 value of the legit site URL, for example: "www.example.com/page.html?a=1".

In order to optimize performance, every request gets cached. Only if it already doesn't exist in cache, Magnitude will fetch the content from the legit site:

The headers also get cached and are served to the victim using the code below:

Then, the content of the page is saved to the $content variable:

The $headers array is saved as a serialized object:

Figure 14. Legit site content and headers get cached

The Fake sites FAQ, located in the Magnitude Management Panel, recommends keeping the fake site option activated for few days. That way it gets tagged as legitimate ads/click brokers' destination. And only then start redirecting to the Magnitude MD server.

Stay tuned for the next blog where we'll continue to examine the Magnitude exploitation flow and present the Magnitude MD server landing-page logic, how Magnitude admins capitalize from the exploit-kit and much more!