Terror exploit kit goes HTTPS all the way
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 used 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:
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.
This is what the traffic looks like using a customized version of the Fiddler web debugger set up as a man-in-the-middle proxy:
Note that the presence of the ‘serve.mfaif.popads.net‘ string within the exploit kit’s URL has nothing to do with the PopAds ad network here. It is simply the name of a directory given by Terror EK’s author.
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:
CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US