BossTDS and Exploit Kits

Download the Appendix – bosstds-and-exploit-kits.xlsx

Appendix A – DNS resolutions for 188.68.252.146.
Appendix B – Advetisement page Whois information.
Appendix C – Host pairs.
Appendix D – Summary of investigations: IPs, domains, redirection methods, EKs, hashes.
Appendix E – BossTDS Whois information.
Appendix F – Additional IP Whois information.

BossTDS Capabilities
Traffic control software, like BossTDS, offers users highly customizable and advanced redirection schemes. Here are some of the more notable filters and features offered by BossTDS:

• Detect and track unique visitors.
• Detect and filter by device type, OS, Browser, manufacturer and engine.
• Filter by request query GET parameters.
• Detect proxies and extract real IPs when possible.
• Detect empty referer.
• Check if client IP falls in a list of IP ranges.
• Filter by countries, configurable country groups and cities.
• Filter by locale of client browser (configured languages).
• Detect if the client accepts cookies.
• Check if HTTP request header with given name matches or not matches given regular expression.
• Detect if client supports JavaScript, flash, if the URL opened in a frame, and Browser window dimensions.
• Check if client already was redirected to some of the URLs (useful for cloaking paid traffic).
• Detect connection type by IP.
• Detect ISP by IP, allows filtering by ISP name.

Other features include:

• Rotate pages (randomly or semi-randomly). Repeated visitors are sent to a new page.
• Dynamically transform target URLs.
• Have unlimited traffic redirection schemes. Have unlimited target pages in each scheme. Assign unlimited filters on each target page.
• Redirect by standard 302 redirect, open target page in iframe, redirect by META REFRESH, redirect by form submit, by JavaScript window.location or by JavaScript link click. Or just return some data as a response in HTML, JSON or JSONP format.

How It Works
One of the important functions of a TDS is to route traffic based on traffic control schemes. BossTDS administrators can create unlimited traffic redirection schemes. Each scheme consists of one IN URL, one Default OUT URL, and one or more OUT URLs.

• IN URL
  • This is the link that is placed on web pages. User click on the links and are sent to the BossTDS. From here the system decides where the visitor will be redirected to.
• OUT URL
  • These are the addresses of web pages that the visitor is redirected to. There are lots of rules to control which, when, and how many visitors should be sent to each of the OUT URLs of each scheme.
• Default OUT URL
  • If no OUT URL was chosen on the previous step due to rule parameters, then the visitor will be sent to the Default OUT URL.

When a visitor hits an IN URL, BossTDS checks all the OUT URLs for this scheme, and if one of the OUT URLs accepts the request, the visitor will be redirected to this OUT URL. Which OUT URL is selected depends on the scheme settings and OUT URLs settings and filters. An example of some OUT URLs are shown below in Figure 1:

In the example shown above you can see that BossTDS has filters for UA (User-Agent) and GEO (geo-location). All mobile traffic will be redirected to yahoo.com via a 302 Found. All non-mobile traffic from Russia would be redirected via a 302 Found to ya.ru. All other traffic would be redirected to bing.com via a 302 Found.

All of the OUT URLs conditions can be edited. This means you can select from multiple redirection methods including:

• JS window.location.href
• JS a[‘href’] click
• JS Form sumbit
• File (200 OK)
• META REFRESH
• Fullscreen iframe
• Pixel
• Flash (page)
• Flash (.swf)

Also, you can edit the rule to accept or reject certain User-Agents. This can be broken down by browser family, browser type, browser engine, browser manufacturer, OS family, OS type, and OS manufacturer.

TDS software can be used for catching bots in huge streams of paid traffic. The second and third most popular ones is increasing conversion by showing different ads for people with different devices and from different countries, and hiding referer and traffic source from the advertisers. Also it is often used for traffic arbitrage – the traffic which is bought in bulk can be resold for much more if it gets turned into targeted traffic (one buyer would buy, for example, “only unique hits from premium countries from iPad”, another one “only two first hits with Android from Cambodia, but no more that 50000 hits/day” etc).

However, it is also being used by cybercriminals. For example, a malicious actor could create traffic redirection schemes to EK landing pages based upon specific attributes. For instance, being able to detect browser attributes prior to redirecting hosts to the landing page could prove to be more lucrative. In the next section I will show how BossTDS servers are being used in the infection chain.

Infection Chains
My research on these BossTDS servers started on November 28th, 2016, when I noticed some odd-looking traffic leading to a RIG EK server. The traffic immediately stood out to me as it was using 302 redirects in the infection chain.

Normally, I would find a compromised website that contained malicious injected script from a specific campaign. Some examples of these campaigns include “pseudo-Darkleech” and “EITest.” Once the compromised site loaded in the browser the host would be redirected to an EK server. The EK server would then determine if the host was using any vulnerable applications. Exploits targeting these vulnerable applications are then sent to the host, followed by a malware payload. Applications that are frequently being exploited by EKs include Flash Player, Java, Internet Explorer, and Silverlight. An example of these redirection chains is shown in Figure 2.

Another commonly seen redirection chain involves the use of malicious advertisements (malvertisements) on websites to redirect hosts to an EK. Malvertising can infect users via two different methods. The first method requires user interaction wherein users must click on the malicious advert to get infected. The second method of infection is through a drive-by-download, which only requires that the user visit the website hosting the malicious advert. See the flowchart below (Figure 3) for an example:

Keep in mind that these are basic examples of infection chains. A more complex example would include additional redirection mechanisms used by threat actors. An example of an additional redirection mechanism is a “gate,” which is a server sitting between the compromised website and the Exploit Kit server. Updating the flowchart to include an external TDS would look something like Figure 4.

This flowchart assumes that the TDS will route the host directly to the landing page. However, depending on the configurable filters, TDSs can also reroute hosts to benign sites like hxxp://bing.com.

Initial Investigation
As stated in the previous section my initial investigation began on November 28th, 2016, when I noticed 302 redirects being used in an Exploit Kit infection chain. The traffic resembled malvertising and there appeared to be an advertisement page between the legitimate website and the Exploit Kit. I decided to recreate the traffic myself by making an HTTP request directly to the advertisement page, GarciniaLiveTrial.club. Figure 5 shows an image of the webpage, which is advertising a weight-loss supplement.

The referer for this advertisement page is unknown; however, we can reasonably conclude that the user was redirected to this domain as it’s not searchable via Google. The likely scenario, which I backup later with web crawler data, is that the user was redirected to this advertisement page through malvertising.

I identified an interesting iframe when inspecting the sites source code. An example of this can be seen in Figure 6.

The iframe contained a URL that was redirecting the host to a directory located on a BossTDS server. BossTDS can be configured to run on port 80 but it uses port 18001 by default, which you can see in the URL. Once the page starts loading in the browser we see the host making a GET request for /in/traf/. Figure 7 shows the TCP stream for that request.

The server’s response message contains “Cowboy” in the header field. Doing a quick Google search for “Cowboy Server” shows that BossTDS is bundled with Erlang and “Cowboy” is a small, fast and modern HTTP server for Erlang/OTP.

The response code is a 302 Found and the new location is /boom/mix.php. Figure 8 shows the request for mix.php and the server’s response.

The server responds with another 302 Found, however, this time we see that the new location is a URL for a RIG-v EK landing page. The EK dropped a downloader which downloaded a keylogger calling itself “XKeyScore.” The full write-up on that infection is located at https://malwarebreakdown.com/2016/11/29/302-redirects-from-traffic-distribution-system-led-to-rig-v-ek-at-194-87-238-156-dropped-downloader-xkeyscore-keylogger/. The next section examines how additional indicators of compromise were collected.

Finding Infrastructure and Additional Indicators of Compromise
The next step in my investigation was to identify other domains that were resolving to 188.68.252.146. At the time of this writing DNS records indicated that there were nearly 55 domains and/or sub-domains resolving to that IP address. The first domain/sub-domain to resolve to 188.68.252.146 was on 7/30/2014. The next domains aren’t seen resolving to this IP until November 2016, more than 2 years later. A full list of domains and/or sub-domains resolving to 188.68.252.146 can be found in Appendix A.

Notice that GarciniaLiveTrial.club is one of the first domains to resolve to 188.68.252.146 and that many of the other domains are advertisements for pharmaceuticals, pornography, and skin care products. After checking each webpage, I could identify 9 domains and/or sub-domains that were at one point redirecting hosts to a TDS server. Domains and/or sub-domains that contained iframes pointing to a BossTDS server include:

• ChatLiveCam.club
• FaceSkinRepair.club
• FindLiveCam.club
• GarciniaLiveTrial.club
• GetVaporDiet.com
• LiveCam.PornTimeGirl.com
• Martina.PornTimeGirl.com
• NewGarciniaTrial.club
• ReduceTheWrinkles.club

The registrar for many of the domains was NameCheap, Inc. while Enom, Inc. was the registrar for LiveCam.PornTimeGirl.com. Unfortunately, all the registrant contact information was protected by WhoisGuard. Getting registrant contact information from WhoisGuard is possible but they require a Subpoena or Court Order. However, Web hosting companies like NameCheap often encourage users to report sites involved in spam, phishing, copyright infringement, fraud schemes, child pornography, malware distribution, trademark infringement, and invalid Whois details. Whois details for the advertisement pages are provided in Appendix B.

Checking the IP resolution history for these domains showed that they were previously resolving to 212.92.127.231 and have been slowly switching over to 188.68.252.146 since November of 2016. Further investigation of 212.92.127.231 shows other suspicious domains resolving to it:

• ClearFaceHappySkin.club
• ImprovedMemoryFocus.net
• PornMeMedia.club
• PornStarCam.club
• RepairPCSafe.club
• VaporDietPlans.com

Web crawler data shows these domains also contained suspicious iframes. However, I can’t say for certain if the IPs within the iframes were pointing to a TDS as many of the domains are no longer resolving.

Moving on, it can be noted that when I identified the iframe on ChatLiveCam.club it had the IP address of 195.154.243.149. Just days later ChatLiveCam.club switched IPs to 162.255.119.214. ChatLiveCam.club is one of the many domains in this report that are no longer resolving (they got flagged as malicious).

As you can see from Appendix B, all the advertisement pages were using the following name servers:

Name Server	IP Resolution	Geo-Location
ns1.offshore-servers.net	212.92.127.231	Russia
ns2.offshore-servers.net	212.92.127.231	Russia
ns3.offshore-servers.net	188.68.252.146	Poland
ns4.offshore-servers.net	188.68.252.146	Poland
iris.ns.cloudflare.com	173.245.58.118	United States
alec.ns.cloudflare.com	173.245.59.59	United States

Offshore-servers.net is owned and operated by the same individual(s) running offshore-servers.com, which has the following sub-domains:

Name Server	IP Resolution	Geo-Location
ftp.offshore-servers.com	144.76.156.230	Germany
ns1.offshore-servers.com	212.92.127.231	Russia
ns2.offshore-servers.com	212.92.127.231	Russia
srv2.offshore-servers.com	188.68.252.146	Poland
srv12.offshore-servers.com	212.92.127.231	Russia

As the domain name suggest, offshore-servers.com offers individuals’ offshore services in numerous locations. Their online advertisements proudly claim “100% DMCA ignored,” meaning that a hosting won’t be taken down due to DMCA complaints. Per their website, they are currently offering shared hosting locations in Russia and the Netherlands, VPS (Virtual Private Server) plans in Ukraine, as well as RDP plans in the Netherlands and France. Previous collocations were in Dominica, Serbia, Italy, Slovakia and Slovenia.

Offshore hosting providers like offshore-servers.com are attractive options for cyber-criminals since DMCA is a U.S. law aimed at U.S. hosts. Sending a DMCA notice to a host located in a country like Russia is a pointless endeavor. Domains that benefit from ignoring DMCA take-down notices include sites that offer individuals the ability to download pirated software (warez sites), music, and movies. The next section will show how hosts were being redirected to the advertisement pages.

Discovering Host Pairs
During my investigation I documented redirections from the advertisement pages to multiple Exploit Kit servers. While this data proved beneficial in researching the relationship between BossTDS and RIG-v Exploit Kit servers it wasn’t helpful in identifying the initial redirection. Remember that my preliminary hypothesis was that hosts were being redirected to these advertisement pages from malvertisements. I believed this to be the case since these advertisement pages weren’t being indexed and thus aren’t going to show up in search engines. Users would have no legitimate reason to visit these sites directly.

I confirmed my suspicions by using data collected by RiskIQ’s web crawler. RiskIQ calls the connections between two domains a “host pair,” stating that “host pairs are two domains (a parent and a child) that shared a connection observed from a RiskIQ web crawl. The connection could range from a top-level redirect (HTTP 302) to something more complex like an iframe or script source reference.” To clarify, the parent page is the referer and the child is the page that the host was redirected to. Having access to this crawl data gave me the ability to see how a user might be redirected to one of the advertisement pages. Furthermore, the crawl data shows the host being redirected to EK servers.

As an example, here are some of the interesting host pairs from NewGarciniaTrial.club:

Hostname	First Seen	Host Pair	Cause	Notes
188.68.234.132	12/6/2016 16:08	child	iframe.src	TDS server
far.herculesbrand.com	12/6/2016 16:08	child	unknown	RIG-v EK (194.87.146.145)
onclickads.net	12/6/2016 22:05	parent	location.refresh	Magnitude EK Malvertising
new.herculesgummies.com	12/6/2016 22:06	child	unknown	RIG-v EK (194.87.146.145)
try.demarcocpallc.com	12/8/2016 23:56	child	unknown	RIG-v EK (109.234.35.39)
onclickads.net	12/9/2016 0:51	parent	redirect	Magnitude EK Malvertising
free.downtowntoledoevents.com	12/9/2016 3:06	child	unknown	RIG-v EK (109.234.33.39)
far.floridaevergladeshouseboatrental.com	12/9/2016 5:16	child	unknown	RIG-v EK (109.234.35.39)
try.midwestmotorcyclebuyers.com	12/9/2016 19:42	child	unknown	RIG-v EK (109.234.35.39)
try.justifiableconstructionworks.com	12/10/2016 2:18	child	unknown	RIG-v EK (195.133.48.182)
type.mulchguystoledo.com	12/10/2016 4:46	child	unknown	RIG-v EK (195.133.48.182)
add.pbj-band.com	12/10/2016 8:40	child	unknown	RIG-v EK (195.133.48.182)
new.sellyouratvnow.com	12/10/2016 17:41	child	unknown	RIG-v EK (195.133.48.182)

We can see that the web crawler caught the iframe containing the IP address of the BossTDS server, 188.68.234.132. It also caught two malvertising chains from onclickads.net, which led to a Magnitude EK server. Lastly, I found 10 instances of the advertisement pages leading to BossTDS server, which in turn would have redirected hosts to RIG-v EK domains. A full list domains and their host pairs can be found in Appendix C.

BossTDS Traffic Redirection Schemes
Now that I have an idea of how the redirection works I wanted to test for news schemes by changing my IP address and User-Agent. What I found is that the BossTDS server was using a geo-location IP filter to redirect hosts to different files. Specifically, if the host had an external IP address located in the USA then it would be redirected to files like “usa.php.” Furthermore, if the host had an external IP from the U.K. then it was redirected to “uk.php.” Lastly, if the host was from any other country it was redirected to “tier1.php.”

In total I tested 8 different geo-locations:

• USA = /modules/usa.php
• U.K. = /lord/uk.php
• Canada = /lord/tier1.php
• Japan = /lord/tier1.php
• France = /lord/tier1.php
• Germany = /lord/tier1.php
• Argentina = /lord/tier1.php
• El Salvador = /lord/tier1.php

During my investigation I also found different relative paths like /boom/mix.php. Unfortunately, I’m unsure of why that happened as I didn’t document my IP address geo-location. Other relative paths that I found were /snews/tier1.php and /snews/usa.php.

Further testing showed that I was redirected to benign sites like bing.com. It appears that there were some conditions that I wasn’t meeting and thus the TDS decided to spit me out someplace safe.

My next test would be changing my browser. I decided to try using Firefox (Mozilla/5.0 Windows NT 6.1; rv:48.0 Gecko/20100101 Firefox/48.0) and was successfully redirected to a RIG-v Exploit Kit pre-landing page. However, the pre-landing page determined that I wasn’t using IE and redirected me to asiaregistry.com, which is a totally legitimate website. The same thing happened when I used Chrome.

This means that the BossTDS servers weren’t filtering out traffic based on desktop User-Agents. As I stated earlier, a TDS could be used to filter out host that aren’t using the desired browser, OS, etc. Having these filters allows the EK server to focus solely on machines it knows it can compromise.

Another pattern that I found during my investigation is that the BossTDS server was using different redirection methods based off the host geo-location. For example, if the host was located in either the USA or U.K. the BossTDS server would return a 200 OK, with a window.location.href pointing to another file on the server. An example of this can be seen below in Figure 9.

On the other hand, every time the host geo-location was anything other than the USA or U.K. the BossTDS server would return a 302 Found containing the new location. An example of this can be seen below in Figure 10.

I didn’t notice any correlation between host geo-locations and what type of EK server they were redirected to. All the EK servers that I found during my investigation were RIG, however, the web crawler data did show that hosts would have been redirected to Magnitude EK. Also, I couldn’t find any correlation between host geo-location and what type of malware payload was delivered by the EK server.

For a complete summary of my infection chains (includes domains, redirection methods, exploits, and malware payloads) please see Appendix D.

Additional Images
BossTDS control panel login:

Advertisement pages and iframes:

More examples: