We’ve been following the Terror exploit kit during the past few months and observed notable changes in both its redirection mechanism and infrastructure, which have made capturing it in the wild a more challenging task.
Unlike the RIG exploit kit, which uses predictable URI patterns and distribution channels, Terror EK is constantly attempting to evade detection by using malvertising chains without any static upper referrers (at least to our knowledge) combined with multi-step filtering in some cases, as well as HTTPS throughout the delivery sequence.
We’ve noticed consistent malvertising incidents via the Propeller Ads Media ad network, followed by the advertiser’s campaign, which we were able to recognize through URI patterns and other identifying creative choices. Ultimately, the ad redirected to the exploit kit’s first check-in page, which acts as both a decoy and launchpad.
Over time, the threat actors behind Terror have been trying to hide the call to the exploit kit. In one example, they created overly long URLs and using obfuscation to mask their iframe. Interestingly, in other sequences, we witnessed an additional type of filtering that uses unique subdomains. The user is first taken to a page whose current theme is cheap flights and hotels, containing what looks like an affiliate link to the travel site expedia.com:
But the main point of focus here is the additional invisible iframe, created with a unique 15-digit subdomain and refreshed for each new visit:
580773189093524.mistake-hexagon.science/haxit.php 319561824482067.mistake-hexagon.science/haxit.php 239878215504660.mistake-hexagon.science/haxit.php 828990124673515.mistake-hexagon.science/haxit.php ...
This iframe is what creates the final call to the exploit kit landing page. We believe this setup may be to prevent replays that attempt to step over the normal redirection flow, although it was only used for a short period of time.
HTTPS all the things
In late August 2017, we saw Terror EK make an attempt at HTTPS by using free SSL certificates, although it kept switching back and forth between HTTP and HTTPS. At times, there also seemed to be problems with domains that had the wrong certificate:
However, in recent days we’ve observed a constant use of SSL, not only for the exploit kit itself but also at the upper redirection stage.
Without using a MITM proxy, network administrators will see the SSL handshake with the corresponding server’s IP address, but not the full URIs or content being sent:
Terror EK is one of few exploit kits to have used SSL encryption this year, the other well-documented one being Astrum EK, used in large malvertising attacks via the AdGholas group. Also, unlike RIG EK, which appears to have permanently switched to IP literal URIs after operation ShadowFall, Terror is making full use of domains using new/abused TLDs.
As usual, Terror EK is dropping Smoke Loader, which in turn downloads several more payloads, likely to generate a lot of noise on the network:
Despite no significant advancement with more powerful vulnerabilities being integrated, exploit kit authors are nonetheless still leveraging malvertising as their primary distribution method and attempting to evade detection from the security community, which they monitor closely.
In light of these new challenges, security defenders must also understand the malicious techniques that are used by threat actors in order to adapt their tools and procedures and keep tracking the new campaigns taking place.
Indicators of compromise
Terror EK-related IP addresses and domains:
18.104.22.168 22.214.171.124 126.96.36.199 yakset.accountant dimplethan.stream edgeelse.science
CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US [Serial Numbers] 03C5BC64ED4CB1331212750F0ECBF7D2EB4E 0337D982AFCC25063A91502A482AAB39A559 [Thumbprints] 73FDC41268FC8B53D37D66BF63FDF71FDF111803 60ADD6955D23029A571BE7F0079C941631CAD32F
3579870858e68d317bb907b6362d956a80f3973c823021d452a077fd90719cdf 99d6c4830605ed61e444c002193da4efe3bc7d015ad230624a2c9aae81982740 a8a8b5ed76019c17add5101b157ab9c288a709a323d8c12dbae934c7ec6e1d14
This is a Security Bloggers Network syndicated blog post authored by Jérôme Segura. Read the original post at: Malwarebytes Labs