IOCs:
- 188.225.36.231 – hand.stayatsouthpadre.com – RIG-v EK
- 31.11.32.225 – www pivesso.us – GET /Img/Gif/oni64.gif – Tor client
- 37.48.122.26 – curlmyip.net – Used for host IP lookup
- Post-infection Tor traffic going over TCP port 9001 – ET POLICY TLS possible TOR SSL traffic
DNS Queries:
- resolver1.opendns.com – ET POLICY OpenDNS IP Lookup
- 222.222.67.208.in-addr.arpa
- myip.opendns.com
Traffic:
Figure 1
Hashes:
SHA256: 0c1b3a0131c98032141d2315902b546bd926d5d4365628dafbbfca165f934f12
File name: RIG-v EK Flash Exploit.swf
SHA256: ddb35d228fbd3cd4d6eb78063bd407e8e95708925e8568bd3b7e7933ad7308c7
File name: QTTYUADAF
SHA256: 2013911086eeba13ee90a57d81a27fabdab52e9896f0ec55e7b9aec0528c57b7
File name: rad1F7D9.tmp.exe and BthMpsvc.exe
SHA256: fda8e2088f7ca3f22d90e0ce3a9e2e466b7a30e96cfc166059156aabab3dea1b
File name: brothers.dll
SHA256: 732459cebedadc55d5011689102d5ad91fe8cbcf40ec9228eaa2e31d2d7a4ecb
File name: oni64.gif
Infection Chain:
This infection chain begins with a malicious iframe being placed on a site:
Figure 2
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:
Figure 3
The GET request for [redacted].biz/1 returns a “302 Moved Temporarily” and points to [redacted]tds.com:
Figure 4
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/:
Figure 5
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:
Figure 6
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):
Figure 7
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:
Figure 8
style_v2_optimized.css returned a page with this iframe:
Figure 9
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:
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%:
Figure 11
The file is also created in C:Users<User>AppDataRoamingMicrosoftApdsclntBthMpsvc.exe:
Figure 12
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!
