Traffic Distribution System is Funneling Traffic to RIG-v Exploit Kit

On November 28th of this year my host was redirected to a RIG-v exploit kit server, however, this time the redirect came from a suspicious looking web page. This was somewhat unusual for me as the majority of exploit kit infections that I deal with begin when a user visits a legitimate site. These vulnerable sites (often WordPress sites) are compromised and are then injected with script designed to redirect hosts to an exploit kit server.

However, this time the web page (referer) looked suspicious as it was promoting one of those shady weight-loss supplements you often see in spam emails. Further piquing my interest was the fact that searching for the domain on Google returned zero results. Most legitimate sites are crawled and will show up in the results of major search engines.

Here is an image of the site. Inspection of the source code revealed an odd looking iframe:

Sure enough that iframe would turn out to be the initial redirection mechanism that led my host to a RIG-v landing page. That infection dropped a keylogger calling itself “XKeyScore.” Click HERE to read more about that infection.

Fast forward a month or so to see that Brad from malware-traffic-analysis.net had also captured a TDS based redirection to a RIG-v EK server.

TDSs being used by exploit kits isn’t new. In fact, it has been used by many different exploit kits over the last couple of years. It was also documented that RIG-E (also known as Empire Pack) was using an internal TDS, however, I hadn’t seen a documented case of RIG-v using TDS (somebody please correct me if I’m wrong). This prompted me to go back and re-investigate the incident that happened back in November.

My first step was to identify other domains that were resolving to the IP address used by the weight-loss supplement web page. My second step was to see if any of those domains contained similar iframes.

Right off the bat I noticed that a lot of the domains looked like they were hosting porn or trying to sell weight-loss supplements and skincare products.

I decided to investigate one of the suspicious porn domains using the .club TLD. Just like with my previous infection the web page contained iframes pointing to the same TDS server (via a direct IP). The only difference this time is that there were two malicious iframes.

Here is an image of the site and the iframes found in the source code (12/21/16):

And here is another webpage from today (12/22/16) that is resolving to the same IP as the other ads:

third-ad-showing-iframe-in-source-code-edited

Out of the 10 or so domains that I looked at these three came back with iframes pointing to the same TDS. Another thing I noticed is that most of these advertisement pages looked similar. For example, here are some of the pages that didn’t contain an iframe:

Attempting to pivot off the Whois information didn’t lead to much. What I can say is that these domains and the TDS are in AS197226.

Continuing the investigation I noticed that the suspicious iframes were all pointing to resources to be accessed via TCP port 18001. A quick Google search shows that TCP port 18001 is used by an application called BossTDS. According to their website, BossTDS is a “user-friendly, fast and feature-rich traffic redirection/traffic control software.” In other words a TDS is a gate that is used to redirect visitors to various content.

TDS software is actually quite robust. For example, here are some filters that BossTDS advertises:

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.

TDS software can be used for legitimate purposes but it is easy to understand how they could be a useful tool for cybercriminals . For example, a malicious actor could create traffic redirection schemes (campaigns) to landing page based upon specific attributes. Being able to detect Browser attributes prior to redirecting hosts to the landing page could prove to be more profitable. Click HERE to read a TrendMicro research paper on TDS being used to distribute malware.

Here is an image of the external BossTDS Control Panel login:

Here is the TDS server responding to the requests generated by the iframes (found in the source code on 12/21/16):

As you can see the server returns a 200 OK with an href pointing to /snews/usa.php and a 302 Found pointing to /snews/tier1.php.

Next we see the GET requests for /snews/usa.php and /snews/tier1.php:

The server’s response to both these files was a “302 Found.” The new locations contained a unique URL pointing to the RIG-v EK server. Specially, these URLs redirected the host to the RIG-v “pre-landing” page that is checking the User-Agent. Click HERE to read more about the “pre-landing” page.

Once the script verifies that I’m not a bot and that I’m using IE the host is redirected to two RIG-v landing pages. Once on the landing pages the host is fed some script and then sent the Flash exploit (same Flash exploit for both infections) and then the malware payloads.

It was at this point that one of the infection chains dropped a downloader (OTTYUADAF) followed by Cerber (in %Temp% circled in pink).

The second infection chain dropped rad6BD05.tmp.exe (circled in yellow in %Temp%). We then see the same file created in ProgramData > Windows Photo Viewer under the name WindowsPhotoViewerR.exe. Notice the file size for WindowsPhotoViewerR.exe is 230 KB and the modification time is 11:53 AM.

Below are images of the files:

Here is an image of the script that dropped rad3CF52.tmp.exe (Cerber) in %Temp%:

Additions to the registry:

After letting the host sit for a couple hours I noticed some odd looking traffic and then I saw that WindowsPhotoViewerR.exe had grown in size from 230 KB to 344 KB and had a new modification time of 2:35 PM. It also had a fresh new Instagram icon:

Running the file again in VirusTotal and Hybrid-Analysis showed it contacting the exact same host as before:

185.82.216.34:80
31.3.135.232:53
144.76.133.38:53

My investigation into the TDS server is ongoing.

Below are the IOCs and hashes collected from the investigation.

IOCs:

195.133.201.36 – far.2playstation.com – RIG-v EK server
185.82.216.34 – guffy.bit – POSTing data back to server
185.82.216.34 – managename.bit – POSTing data back to server
Post-infection DNS traffic:
- 31.3.135.232 – Switzerland
- 144.76.133.38 – ns1.opennameserver.org – Germany
Cerber Check-in traffic via UDP port 6892:
- 77.4.1.0/27
- 77.15.1.0/27
- 91.239.24.0/24 – Responses showing destinations are unreachable
- 91.239.25.0/24