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.

RIG Exploit Kit Infection Cycle Analysis

Overview

Happy belated birthday to RIG exploit kit! First seen around April 2014, RIG has been in the news several times over the past year. In February, the source code was reportedly leaked online, which likely spurred some of the recent changes we've observed in the kit. ThreatLabZ has been keeping an eye on RIG and in this post we'll cover an example of a full RIG infection cycle.

Delivery

In the past, RIG used malvertising and compromised sites to send users to RIG landing pages and we've seen no change in this tactic. Compromised sites leading to RIG usually contain an iframe in the page header that loads a RIG proxy domain, which also contains an iframe leading to the RIG landing page. The full infection cycle is shown in the annotated Fiddler session below.

Fig 1: RIG Infection Cycle

In this example, the compromised site actually contains three different malicious iframes in its header. These iframes correspond to line items 37-39 in Fig 1.

Fig 2: iframes on Compromised Site

Out of the three RIG proxy iframes on the compromised site, only one, sunfuji[.]com, is still redirecting victims to RIG landing pages. Much like the iframe on the compromised site, the RIG proxy page contains an iframe redirecting victims to the actual landing page.

Fig 3: RIG Proxy Redirects to RIG Landing

Note that the RIG proxy is a persistent redirector, which will change the landing page location arbitrarily. Taken at a different time, the same page returned the following result:

Fig 4: RIG Proxy Changed Landing Page

Landing Page

The landing page has multiple consistent attributes, starting with the URI. Every RIG landing page URI starts with a question mark, followed by 171 characters. Two examples are below:

• four.pavementexpress[.]org/?xH6Af7ieJRvHDIs=l3SKfPrfJxzFGMSUb-nJDa9GPkXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFT_zR3AaQ4ilotXQB5MrPzwnEqWwxWeioWBrxaIYwMU95LEQOdviwijm7VFJMonk0DRvWcDnrtMU0gbrA
• trip.slotsbid[.]com/?xniKfredKx_HCYY=l3SKfPrfJxzFGMSUb-nJDa9GPkXCRQLPh4SGhKrXCJ-ofSih17OIFxzsmTu2KV_OpqxveN0SZFT_zR3AaQ4ilotXQB5MrPzwnEqWwxWeioWAqBHbYw1MrcOTEOcz0Aj2yeVBd892zxWA4GMBmL5MVUgbrA

The landing page itself contains three blocks of obfuscated code along with some portions of text from a popular CNET article. The majority of the code is actually a long list of character-delimited strings that are passed to a function that basically splits them on the delimiter and runs 'fromCharCode':

Fig 5: Top of the RIG Landing Page - strings use 't' delimiter

The decode function for each of the three code blocks immediately follows the set of character-delimited strings, as shown in Fig 6.

Fig 6: Decode function for first set of character-delimited strings

The deobfuscated first block of code attempts to detect known virtual machine characteristics and other attributes that might indicate an analysis environment. If anything is found, the next two code blocks are not deobfuscated or executed.

Fig 7: Code block 1 deobfuscated - detect analysis environment

The second code block is a large base64-encoded VBScript segment:

Fig 8: Code block 2 deobfuscated - vbscript

The VBScript is executed from the following code:

 function time() {window.execScript(base64_decode(scriptvar), "VBscript");}setTimeout(time, 3001);  

Once executed, the VBScript exploits CVE-2014-6332, the so-called 'Godmode' exploit (VT detection - 4/57). AV detection tends to be particularly bad on the VBScript even though the code very closely matches the proof of concept originally publicized. There is a good writeup from TrendMicro, which delves into the details of this vulnerability. If exploitation is successful, the encrypted exe is downloaded, decrypted, and executed on the system. The encryption key for the binary is conveniently in cleartext within the VBScript:

      If objHTTP.Status = 200 Then  
           Set objFile = objFSO.CreateTextFile(strSaveTo,True)  
           objFile.Write EnDeCrypt(ByteArray2String(objHTTP.responseBody), "nkiOaWsg")  
           objFile.Close       
      End If  

The third block of code simply serves up a malicious SWF with no secondary obfuscation:

Fig 9: Code block 3 deobfuscated - malicious SWF

This code is almost the same as in other exploit kits, and the URL of the encrypted binary is being passed to the SWF as a parameter. The exploit in this case was CVE-2015-0313, which affects Flash versions prior to 16.0.0.305, and the exploit code is contained in a script called 'wow.' Detection on VirusTotal shows 10/57, and there are several public writeups on this vulnerability.

Payload #1 - Injector

The binary payload is encrypted with an 8-byte key, which you can guess from the stream or retrieve from the deobfuscated VBScript.

Fig 10: Encrypted Binary - key is 'WsgnkiOa'

VirusTotal detection is a bit better than 50% for this payload at 32/57. The binary file is a Nullsoft Installer self-extracting archive and extracting the archive reveals three files inside:

Fig 11: Extracted Files from EXE

In addition to these three files, another executable 'b8.exe' is dropped. Once the installer finishes dropping files, it loads the DLL (15/55 on VirusTotal) and begins executing functions to read in the other two files. The file '6ag1rqashtwqw1hgqa' contains data XOR'd with the first 10 bytes of the filename, and the decrypted contents reveals several API calls that give us an idea of what will happen next, for example CreateProcessA, WriteProcessMemory, and ResumeThread.

Fig 12: Decrypting file data with filename

Similarly, the 'Stevie Nicks' .m3u is unfortunately not actually a playlist, but instead an encrypted binary that is decrypted by the DLL using the XOR key "ZhmGqqKwXmJiiS7dzjzPyyaTw0PANF".

Fig 13: Decrypting 'Stevie Nicks' playlist binary

VirusTotal detection on the decrypted Stevie Nicks binary is 35/56.  Ultimately, this leads to creating a hollow process of itself (process hollowing - PDF) which then creates an explorer.exe process and injects code to beacon to the Command & Control (C&C) server. Beacons were frequent and used the URI string '/power/logout.php' to POST to the domain 'starpowerss.com'

Fig 14: C&C Traffic Sample

Other notable activity includes:

• Copying to 'C:\Program Files\Common Files\Windows Search 5.3.10\<random>.exe'
• Using the registry for persistence
• Hooking ZwOpenFile and ZwOpenProcess
• Clipboard control

Payload #2 - Blue Bot

After quite some time, a second payload is downloaded named 'cfajrs.exe' from 'a.pomf.se' which beacons to 141.138.157.240. Four URIs were observed:

• /help/proxy
• Returns a list of 4032 IP:PORT pairs (paste of IP:PORT data)
• /help/blog
• Returns a list of 798 URLs that appear to be blogs (paste of blog data)
• /help/botlogger.php
• Returns div of HTML with "visitors online" (see Fig 15)
• /help/target
• Returns 'STOP|STOP|STOP' during analysis (see Fig 16)

Fig 15: /help/botlogger.php response

Fig 16: /help/target response

VirusTotal detection is 41/56 and indicates this is part of BlueBotnet. Looking at the binary, we see it's a .NET executable and uses no obfuscation at all to make decompilation difficult. Looking at the namespace and classes confirms this is called 'Blue_Botnet' and appears to be a DoS tool.

Fig 17: Blue_Botnet Code Overview

One of the more interesting functions is the 'updateTarget' function, which expects a pipe-delimited list of IP, port, and method. There are multiple different methods accepted for the 'target' command: UDP, TCP, SYN, MCBOTALPHA, HTTP, HTTPROXY, PRESS, and STOP.

Fig 18: Blue_Botnet updateTarget Function

To perform its attacks, the bot has a list of 37 different user agent strings to make detection more difficult (paste of user agents); each request uses a different user agent from the list so requests look like they are coming from multiple different clients instead of from the same source. There is an Italian-language theme to the code, both in some of the variable names and in some of the HTTP headers, for example the Accept-Language header in the HTTP attack function shown below.

Fig 19: Blue_Botnet HTTP Attack Function

Interestingly, the response from botlogger.php is not used in the code and the request may simply be a beacon to the server to keep count of infections.

Conclusions

RIG continues to be a popular and effective exploit kit choice and has evolved over the past year, indicating active development. While other exploit kits are moving toward ransomware and adfraud for monetization of infected victims, RIG is apparently not following this trend and still pushes more traditional malware. ThreatLabZ will continue to monitor RIG for any new developments. For a look at the infrastructure supporting RIG, Trustwave has a great post on the topic.

RIG EK outbreak continues

During daily data mining activities, we observe continual outbreaks of many exploit kits (EK) such as RIG EK. Logs are monitored and analyzed to come up with new protections, which are eventually deployed in the Zscaler cloud. The dynamic nature of EK’s landing page code, presents a constant challenge in providing generic detections. We need to take a look at various aspects of EK’s such as URLs/Domains/IP’s to come up with a generic detection guidance. In this regard, log analysis plays an important role. 

In this blog we'll take a look logs from  last week (8/28/2014 - 9/5/2014), observed for RIG EK.

RIG EK Traffic (%)

The above chart illustrates the traffic trend of RIG EK over the past week. There was a significant spike noted on Sept. 4th. 

Sept 4th Domains/IP:

Domains	IP
eir.alexandrajarup[.]com	194.58.101[.]24
eir.alexandrajarup[.]com	194.58.101[.]24
uiue.nuiausqas[.]com	194.58.101[.]24
iow.alanmccaig[.]com	191.101.14[.]125
ods.alankellygang[.]com	191.101.14[.]125
uew.alankellygang[.]com	191.101.14[.]125
soi.alankellygang[.]com	191.101.14[.]125
eur.alankellygang[.]com	191.101.14[.]125
sod.alankellygang[.]com	191.101.14[.]125
soa.alankellygang[.]com	191.101.14[.]125
lol.alankellygang[.]com	191.101.14[.]125

Sept 4th EK URLs:

Sept 4th common URL pattern:

[.]com/?PHPSSESID=njrMNruDMh7HApzBKv7cTKZNKU7YHVnYmMzMhe6JVg

RIG EK landing page content:

RIG EK Landing Page

Code analysis of the landing page shown above is not discussed here. For a full code analysis, please take a look at our blog post from last month. In that blog, we tried to come up with a generic de-obfuscation technique that helps to de-obfuscate the EKs such as RIG and Fiesta.

Let's now take look at the overall traffic distribution by IP for the last week (8/28/2014 - 9/5/2014).

Traffic distribution by EK IP's

Traffic was observed from 13 unique IP addresses. IP '191.101.14[.]125', was seen to be spreading the EK's in large volumes. We also observed many IP addresses falling into three subnets. 194.58.101[.]XXX 191.101.13[.]XXX 191.101.14[.]XXX We recommend blocking the aforementioned IP's. Subnet level blocks can also be used but we have to be bit cautious when doing so as legitimate sites may also be hosted in the same range. The following world map illustrates the geographical distribution of the EK IP's which have been observed. As noted, most activity is emanating from Russia.  Geo-graphical distribution by EK IP's

No geo-location information was available for IP's falling into '191.101.XX.XX' subnet.

Below is the full list of domains and IP's seen for the previous week.

Domains	IP
tue.allthatsin[.]com	178.132.203[.]113
qie.allthatsin[.]com	178.132.203[.]113
dfu.aloliskincare[.]com	194.58.101[.]38
uer.alistairnunes[.]com	194.58.101[.]31
eir.alexandrajarup[.]com	194.58.101[.]24
oweuryt.account-ltunes[.]com	191.101.13[.]139
teyruyt.a[.]commodationinsauze[.]com	191.101.13[.]139
weorioi.a[.]commodationinsauze[.]com	191.101.13[.]139
owiery.wikusbotha[.]com	191.101.13[.]140
nuaysuq.planeimpressions[.]com	5.31.72[.]115
suyfdys.online-moneymakingsystem[.]com	5.31.72[.]115
iuiweyr.online-moneymakingsystem[.]com	5.31.72[.]115
oweiru.laughterisgoodmedicine[.]com	5.31.72[.]115
woiero.laughterisgoodmedicine[.]com	5.31.72[.]115
aosidoa.kensymicek[.]com	191.101.13[.]202
sdfusug.kensymicek[.]com	191.101.13[.]202
qwieuu.kensymicek[.]com	191.101.13[.]202
iuasid.kensymicek[.]com	191.101.13[.]202
odigoud.helny[.]com	191.101.13[.]202
qoiweur.helny[.]com	191.101.13[.]202
miiuis.helny[.]com	191.101.13[.]202
oeriouh.francisssmith[.]com	191.101.13[.]202
dciugi.francisssmith[.]com	191.101.13[.]202
gdofigu.forgottenapples[.]com	191.101.13[.]201
miqwue.boxsteravatar[.]com	191.101.13[.]200
popoqwe.dukeanddiva[.]com	191.101.13[.]201
mbivuc.click2maps[.]com	191.101.13[.]201
oiqwour.click2maps[.]com	191.101.13[.]201
mbivuc.click2maps[.]com	191.101.13[.]201
oiqwour.click2maps[.]com	191.101.13[.]201
oiaosdu.bluffswebdesign[.]com	191.101.13[.]201
dwieru.bluffswebdesign[.]com	191.101.13[.]201
nuasiud.amiramatthews[.]com	191.101.13[.]200
miuggid.748tmp[.]com	191.101.13[.]200
owierowu.748tmp[.]com	191.101.13[.]200
eoitoe.boxsteravatar[.]com	191.101.13[.]200
miqwue.boxsteravatar[.]com	191.101.13[.]200
wueriq.boxsteravatar[.]com	191.101.13[.]200
naduq.00tim[.]com	191.101.13[.]198
miasud.bigredshed.org[.]uk	191.101.13[.]198
qiuwer.121sky[.]com	191.101.13[.]198
digudyfg.belucent.co[.]uk	191.101.13[.]196
woiero.beauchamplondon.co[.]uk	191.101.13[.]196
eir.alexandrajarup[.]com	194.58.101[.]24
uiue.nuiausqas[.]com	194.58.101[.]24
iow.alanmccaig[.]com	191.101.14[.]125
ods.alankellygang[.]com	191.101.14[.]125
uew.alankellygang[.]com	191.101.14[.]125
soi.alankellygang[.]com	191.101.14[.]125
eur.alankellygang[.]com	191.101.14[.]125
sod.alankellygang[.]com	191.101.14[.]125
soa.alankellygang[.]com	191.101.14[.]125
lol.alankellygang[.]com	191.101.14[.]125
kick.alankellygang[.]com	191.101.14[.]125
sdifu.alanhalldriving[.]com	191.101.14[.]125
pqqie.alanhalldriving[.]com	191.101.14[.]125
weoriuwyt.alanhalldriving[.]com	191.101.14[.]125
oigydfg.alanhalldriving[.]com	191.101.14[.]125
oiweyr.alanhalldriving[.]com	191.101.14[.]125
fgydy.ajrobertsconsulting[.]com	191.101.14[.]125
husaus.ajrobertsconsulting[.]com	191.101.14[.]125
super.affogatomoments[.]com	191.101.13[.]139
iuweryw.activity-partners[.]com	191.101.13[.]139
weorioi.a[.]commodationinsauze[.]com	191.101.13[.]139
owiery.wikusbotha[.]com	191.101.13[.]140
oiqwour.click2maps[.]com	191.101.13[.]201
oiaosdu.bluffswebdesign[.]com	191.101.13[.]201
dwieru.bluffswebdesign[.]com	191.101.13[.]201
owierowu.748tmp[.]com	191.101.13[.]200
eoitoe.boxsteravatar[.]com	191.101.13[.]200
miqwue.boxsteravatar[.]com	191.101.13[.]200
qiuwer.121sky[.]com	191.101.13[.]198

The above trend shows a continuous outbreak of RIG EK in the wild. Data mining logs for such activity provides us with a sense of the trends being followed by the attackers. We will keep on sharing such information via blogs/scrapbook posts. 

Stay tuned! 

Pradeep