Fiesta Exploit Kit Analysis

[ccesar]

Fiesta Exploit Kit Analysis

In January, Cisco published a blog post on the ubiquitous Fiesta Exploit Kit (EK) which is quite active at the moment. To supplement their analysis, this post takes a look at an individual Fiesta drive-by attack observed by Context as part of our managed Targeted Attack Detection Service (TADS). The post also shows the methodology we used to investigate the incident and decode the traffic.

Compromising a user through a drive-by web attack certainly isn’t new, but due to advances in the detection of phishing emails it is becoming an increasingly popular alternative. Another drawback for the attacker when relying on phishing attacks to deliver malicious code is that an email often contains clues such as sender addresses and information in SMTP headers. This makes it easier for email scanners and intrusion detection systems to identify and attribute further attacks.

In the case of Fiesta, the perpetrator(s) of this activity appear to have compromised numerous webservers in order to inject their malicious code into webpages. The result is a potential victim pool of thousands of browsers visiting those sites; an ideal attack platform for those who are trying to compromise as many online bank accounts as possible using crimeware.

What makes this attack vector all the more insidious is that the only parties likely to detect malicious code delivered server-side are the administrators for the websites and those who have the resources to implement technical countermeasures - certainly not the average user. This is in contrast to a phishing email, where it only takes one recipient to become suspicious and alert the appropriate authorities.

This post looks into the methods employed by the Fiesta EK to shed some light on how this kit is able to change its code and avoid being detected.

Compromise stages

1. The exploitation process starts off with a user visiting a trusted webpage containing embedded malicious JavaScript.

2. An embedded script tag on the compromised website causes the user’s browser to request and execute further code hosted on a second domain (In this case valeriesn[.]com).

This domain acts as an intermediary between the original compromised webpage and the Fiesta EK landing page as shown in the image below. This approach gives the attacker much greater flexibility regarding where the victim browser is directed to. They could be sent to different domains hosting the exploit kit, to a different exploit kit entirely, or even nowhere if the attacker does not want to raise suspicion. This provides a layer of adaptability and security to the attacker and aids against detection and disruption of the campaign.

3. When the user’s browser visits the landing page, it is profiled to detect possible attack vectors. As shown in the image below, Fiesta then attempts to exploit the victim browser by directing it to one or more encoded URL addresses:

While the Fiesta Exploit Kit is capable of serving many different exploits, in this particular case Context observed exploits for the following CVEs:

CVE-2013-2465

CVE-2013-1493

Decoding Fiesta EK code

The landing page consists of a large amount of JavaScript code embedded within a HTML document. Almost every aspect of this page can be changed to evade detection, including the page title, variable and function names, and strings in the code.

The Fiesta EK goes to great lengths to obfuscate its code and uses a function to encode the majority of the strings using a number and key combination. The function responsible for this process can be seen below:

The long string stored in the variable “b” is the key used to encode the strings in the document.

In order to reliably decode the contents of the encoded strings in Fiesta EK pages, Context recreated this function in the form of the following Python script:

A copy of this script can be downloaded from here.

When we ran this script against our sample file we received the following output:

From this list of strings Context was able to identify a number of potential attack vectors included in the script.

After a delay of approximately 10 minutes from the drive-by attack two executable files were observed being downloaded by the host from the IP address 115.47.49.181 (Beijing, China).

At the time of writing ‘clock.exe’ was identified as malicious by 33/46 VirusTotal vendors with the majority calling it ‘Papras’:

(https://www.virustotal.com/en-gb/file/041fce3bdcf15db414b2ea47e47b07fcf605749237b2471a5a54da4318b5e0a8/analysis/)

According to F-Secure, ‘Papras’ is a Trojan that steals login credentials and uses a rootkit to hide itself.

The file ‘setini.exe’ was detected by 23/47 VirusTotal vendors was identified by the name ‘Pony’ and ‘fareit’ amongst others.

(https://www.virustotal.com/en-gb/file/b8637fae5a01780c7db6b7150e80a77e90e57613bcf86e1fe555115116c011ec/analysis/)

This file is an information stealer that is also used to download additional malware such as Zeus.

Sadly, the home user has little chance to determine whether malicious code has been injected onto a webpage. As always, keeping browser patching levels up to date drastically reduces the attack surface area as the exploit kit will have fewer or no vulnerabilities to exploit. But if your organisation isn’t willing to carry this risk, you may want to consider in-depth network monitoring.

Thanks to Cisco for raising Fiesta in their post and the original groundwork by malware don’t need coffee. Thanks also to the excellent Kahu Security for the background information.

Sursa Context ? Information Security