- 18.104.22.168 – hand.stayatsouthpadre.com – RIG-v EK
- 22.214.171.124 – www pivesso.us – GET /Img/Gif/oni64.gif – Tor client
- 126.96.36.199 – curlmyip.net – Used for host IP lookup
- Post-infection Tor traffic going over TCP port 9001 – ET POLICY TLS possible TOR SSL traffic
- resolver1.opendns.com – ET POLICY OpenDNS IP Lookup
File name: RIG-v EK Flash Exploit.swf
File name: QTTYUADAF
File name: rad1F7D9.tmp.exe and BthMpsvc.exe
File name: brothers.dll
File name: oni64.gif
This infection chain begins with a malicious iframe being placed on a site:
The site doesn’t appear to be a decoy site as it has been around since late 2012. The domain within the iframe tags using the .biz TLD is a Keitaro TDS server. I know this because I found the login page for the TDS server:
The GET request for [redacted].biz/1 returns a “302 Moved Temporarily” and points to [redacted]tds.com:
The host then makes a GET request for [redacted]tds.com. I found at least 208 directories on [redacted]tds.com while I was hunting for additional intel; however, there are likely a lot more. I wouldn’t be surprised if going to each of these directories would result in a similar infection chain. One directory I was able to locate was a WordPress login page at [redacted]tds.com/wp-admin/:
It’s not using HTTPS and the credentials were being sent in the clear.
I was able to determine the following components associated with [redacted]tds.com:
- Server = Apache
- Framework = PHP
- CMS = WordPress
Changing only the destination port to 2083 resulted in a 302 redirect to a cPanel login page:
To be clear, cPanel is a web based hosting control panel provided by many hosting providers to website owners allowing them to manage their websites from a web based interface. The actual hosting provider for [redacted]tds.com is qhoster.net.
Picking up from where we left off, [redacted].biz redirected the host to [redacted]tds.com. The host then makes a GET request for [redacted]tds.com and the server returns a page containing a malicious iframe (found at the very bottom):
The iframe at the bottom of the page contains the URL for the RIG-v EK pre-landing page. We can also see that there are two GET requests for .css files which is caused by the link href’s. I only mention these two GET requests because the both returned pages containing iframes that pointed to RIG-v EK pages:
open_sans.min.css returned a page with this iframe:
style_v2_optimized.css returned a page with this iframe:
Neither of the iframes (shown in Figure 8 and 9) caused my host to make GET requests.
Continuing the investigation we see the GET request for the pre-landing page (circled in red in Figure 7). The server responds with the pre-landing page which has script to make sure the browser is IE, is not a crawling bot, and it is exploitable. The pre-landing page also contains the URL for the RIG-v landing page. If the host passes the checks it is redirected to the landing page via a POST request.
For a summary of the redirection chain please reference Figure 10:
We then see cmd.exe create QTTYUADAF in %Temp% and execute it. The script causes the host to make a GET request for the malware payload. The malware payload (rad1F7D9.tmp.exe) is dropped and executed in %Temp%:
The file is also created in C:\Users\<User>\AppData\Roaming\Microsoft\Apdsclnt\BthMpsvc.exe:
Here is the Hybrid-Analysis report for this sample:
The were also some registry entries created, one for the Tor client that was downloaded and the other for persistence:
If you’re working in a NOSC I would recommend blocking the RIG EK IP address. I’ve also been noticing a lot of infections involving the Tor post-infection traffic. I can’t think of a good reason why Tor would be allowed on a corporate network so scanning them for common Tor ports might be a good idea.
Until next time!