Actor using Rig EK to deliver Qbot - update

Published: 2015-12-30
Last Updated: 2015-12-30 05:15:32 UTC
by Brad Duncan (Version: 1)
8 comment(s)


This diary is a follow-up to my previous diary on the actor using Rig exploit kit (EK) to deliver Qbot [1].  For this diary, I've infected more Windows hosts from other compromised websites, so we have additional data on this actor.

As previously noted, this actor has been delivering Qbot (also known as Qakbot) malware.  The actor uses a gate to route traffic from the compromised website to the EK landing page.  In this case, the gate returns a variable that is translated to a URL for the EK landing page.  The sequence of events is:

  • User visits a website compromised by this actor.
  • An HTTP GET request for a .js file from the compromised site returns text with malicious script appended to it.
  • An HTTP GET request to the gate returns a variable used by the malicious script.
  • The variable sent by the gate is decrypted, and an HTTP GET request for the EK landing page is sent.


I've collected more samples of Rig EK infections from this actor as shown below.  Of note:

  • The first line is the .js file from the compromised website with malicious script appended to it.
  • The second line is the gate used by this actor.
  • The third line shows the IP address and domain name for Rig EK used by this actor.

The following four infection occurred within the past 24 hours:

  • 2015-12-29 20:51 UTC - - GET /public/temp/js/jquery.js
  • 2015-12-29 20:51 UTC - port 80 - - GET /mmviewforumboiu.php
  • 2015-12-29 20:51 UTC - port 80 - - Rig EK
  • 2015-12-30 00:38 UTC - - GET /rsc/js/jquery.min.js
  • 2015-12-30 00:38 UTC - port 80 - - GET /omoviewforumfjcic.php
  • 2015-12-30 00:38 UTC - port 80 - - Rig EK
  • 2015-12-30 01:04 UTC - - GET /public/temp/js/jquery.js
  • 2015-12-30 01:04 UTC - port 80 - - GET /lvviewforumilu.php
  • 2015-12-30 01:04 UTC - port 80 - - Rig EK
  • 2015-12-30 01:16 UTC - - GET /clientscript/vbulletin-core.js?v=422
  • 2015-12-30 01:16 UTC - port 80 - - GET /auqviewforumixx.php
  • 2015-12-30 01:16 UTC - port 80 - - Rig EK

Below are images of pcaps from the traffic filtered in Wireshark.  The last pcap shows post-infection traffic similar to what we saw in my last diary about this actor [1].

The FTP server shown in the last example had information from my infected host, along with other infected hosts.  As the actor collected files from that FTP server, they would periodically disappear, and new files would appear as other hosts became infected from the malware.

Gate traffic review

Although I went over it in my last diary, let's review again how the gate traffic works.  First, we get the malicious script added to a .js file from the compromised website.  It's usually appended, and you'll find it at the end.  I've also seen the malicious script at the beginning of the .js files.  It might take a while for people to find it, but it's there.  The image below shows the appended script to vbulletin-core.js from the compromised website in the last pcap.

The first highlighted section shows how the value from the main_color_handle variable is translated by replacing all symbols with a % and replacing all alphabetic characters g and higher with nothing.  This returns a through f and 0 through 9 that will be grouped as two-character hexadecimal pairs, with a % before each pair.

The second highlighted section shows the URL for the gate.  As I mentioned in my previous diary about this actor, the text is obfuscated, so it's not easy to find.  However, if you know what you're looking for, you can find it.

This injected script calls the main_color_handle variable from the gate URL and translates the variable to the EK landing page URL.  See the image below for details.

Final words

Today's diary provides more examples of Rig EK infections by this particular actor.  Hopefully, it provides a better understanding of the infection traffic.  If anyone has access to your organization's web proxy logs, search for and see if the HTTP GET requests follow the patterns seen in this diary.  If you can find the referer for that HTTP GET request, you may have discovered another website compromised by this actor.

Pcap and malware samples used in this diary are available here.

Brad Duncan
Security Researcher at Rackspace
Blog: - Twitter: @malware_traffic



8 comment(s)


Another great article from Brad.

I would like your advise with regards to the analysis. Currently I investigate all spams with URL and attachments to identify new/known malware and also go through your blog for exercises. I want to know what other methods are good to collect malware.I understand you have lab environment - is it possible that you can share what you lab environment is like ?

I use Security Onion and tools within to investigate any suspicious/malicious files.Also, havee a cuckoo sandbox.

Do you have special honeypot for this ? I am really interested in identifying whatś out there but seems to be lost at times ? Appreciate your any guidance.
[quote=comment#35995]is it possible that you can share what you lab environment is like ?[/quote]

Most people (including me) won't share that sort of information. Why? Just like we monitor the bad guys, those bad guys also keep an eye on us, and they change their tactics as necessary. For example, some exploit kits detect if your Windows host is running as a virtual machine on VMware. If that's the case, you won't get past the exploit kit's landing page.

I've also run across plenty of malware samples that look for VMware when infecting a Windows host. In fact, much of the malware out there has some sort of anti-forensic capabilities.

Because of that, I sometimes use a physical Windows host (not a VM) when checking things out. But as I've already mentioned, I won't share the details on how it's configured.

When I first started looking at malware, I'd often check Clean MX Virus Watch and for samples.
These posts are incredibly helpful.

I was able to go back through our logs and found one hit on

Replaying that user's browsing session in a sandbox gives me:

Accept: application/javascript, */*;q=0.8
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Wed, 30 Dec 2015 17:54:04 GMT
Content-Type: text/javascript; charset=ISO-8859-1
Connection: keep-alive
P3P: policyref="/w3c/p3p.xml", CP="policyref="/html/p3p.xml", CP="NON DSP COR NID DEVa PSAa PSDa OUR BUS""
Set-Cookie: fltna=DekbADIAAgAOADwahFb__zwahFZAAAEAAAA8GoRWAA--; expires=Thu, 29-Dec-2016 17:54:04 GMT; path=/;
Content-Length: 26

var main_color_handle='';
Thanks, Dan! Looks like you found another website compromised by this actor (from the referer line).

We certainly appreciate the info.

- Brad
I'm relatively new to this, so if I'm wasting my time, please tell me :-)

I expanded the time frame on my search to go back 60 days, and I've got two more compromised sites.



It's odd how the .php in my samples is only 26 bytes, and only contains:
var main_color_handle='';
I was expecting to see more.

When you come across sites like this, do you attempt to contact the site owners? I think about doing that, but I wonder if my boss would prefer that I spend my time on something else.
It's odd how the .php in my samples is only 26 bytes, and only contains:
var main_color_handle='';
I was expecting to see more.

When you come across sites like this, do you attempt to contact the site owners?[/quote]

Thanks again for the additional referers, Dan.

There are a few conditions that must be met before the main_color_handle variable is sent. For example, the host doing the HTTP GET request should be a Windows host. If not, you'll probably get nothing in return for the main_color_handle variable (which is what you got... Nothing between those two single quote marks).

I generally haven't attempted to contact the site owners. There's just too much out there, and I'd be spending a lot more time notifying people and less time doing actual research. If I do an entry about it on the my regular blog site, the info will usually make its way back to the site owners (usually because the site ends up on someone's blacklist). There are usually other higher-priority issues to take care of, and most bosses want to block the site and have us move on to the next suspicious event.

- Brad
Thanks Brad for th response. I understand that as we are watching them, they are watching us.

I will check out the sites you mentioned and do a bit more research in these area.

thanks again...Happy New year.
Thanks to Dan and another person who sent me more referers, I've generated 8 more infections and the associated malware/artifacts. If anyone is interested, the information is available at:

Diary Archives