Beta exploit pack: one more piece of crimeware for the infection road!

2015-06-18

Aditya K. Sood

Michigan State University, USA

Rohit Bansal

Independent Security Researcher, USA
Editor: Martijn Grooten

Abstract

Beta BEP appears to be the latest exploit kit in development. After finding their way into a Beta BEP C&C panel, Aditya Sood and Rohit Bansal were able to gather intelligence about the structure and working of the exploit pack. Here they share their findings about the pack - which they believe we will start to see being used in the coming months.


Browser exploit packs (BEPs) or exploit kits are used extensively in drive-by download attacks to infect target systems on the Internet. BEPs are used to distribute advanced malware to end user systems after exploiting vulnerabilities in browsers’ components or embedded plug-ins. BEPs are hosted on compromised domains and victims are coerced into visiting those domains either through spear phishing or through URLs shared on social networks and so on. On visiting a compromised domain, the victim’s browser is fingerprinted and if a vulnerable component is found, the respective exploit is served and malware is downloaded onto the system. In previous papers, we have presented details of the BlackHole [1], Sweet Orange [2] and Styx [3] BEPs to highlight their design and tactics. Several of the techniques used by Beta Browser Exploit Pack (Beta BEP) are very similar to those used by these exploit packs.

Beta BEP (which is unrelated to the Beta bot) is the latest exploit kit in development. At BlackHat USA 2014 [4], we discussed several fundamental weaknesses in the command and control (C&C) panels used by various pieces of crimeware. The idea of that research was to look for potential issues in web-based C&C panels and to reveal how to find security flaws in them in order to gather intelligence. It came as no surprise that we were able to find our way into a Beta BEP C&C panel and gather some intelligence about the structure and working of the Beta exploit pack. The author of the exploit pack did revoke and take down the panel shortly after we had found our way in, but not before we had extracted some meaty details from it.

We have been studying this exploit pack and gathering data for several weeks now – publishing delays are an unavoidable part of the process of releasing intelligence. Meanwhile, we discovered that another researcher had released an analysis of a very similar exploit kit under the name of ‘Sundown EK’ [5]. In his analysis, the researcher covered details of the network traffic and how the infection is triggered. He reported certain things that are very similar to what we found in our analysis of Beta BEP, as well as some that are slightly different:

  1. The BEP under discussion in this article is sold in the underground market under the name of ‘Beta’; the one analysed in [5] has been given the name ‘Sundown’ by the researcher who discovered it. The analysis of Sundown covers the BEP’s initial testing URLs, which is why the exploits used and URL structure are similar in nature to those we see in Beta.

  2. In [5], the version of Sundown analysed is ‘0.1a’, whereas we analysed version 3.0 of Beta BEP. The author of the exploit kit actually claims Beta as copyleft (a method of making software free so that it can be modified and extended by other developers, thereby maintaining the ‘free software’ clause). We are not sure that copyleft makes any sense in the context of software that is sold in the underground market, and if source code is shared it will be modified accordingly.

  3. The Sundown exploit kit is still under development and it appears that the author is testing it for effectiveness. We have not encountered any real-time cases of Beta BEP version ‘3.0’ being used in the wild, but since it is also in a testing phase, we believe that it will be running live somewhere privately. We tried to access the configured URLs we found in the C&C but all of the domains had been taken down and no active infection URLs were detected.

  4. The rental price of Beta BEP is between $2,000 per month and $100 per day.

As a research community, it’s always good practice to collaborate and share intelligence so that we can tackle issues in a more granular way.

C&C panel

Primarily, the Beta BEP consists of the following components:

  • A component for collecting statistics on successful infections.

  • A component that will upload a malicious executable and check whether it can bypass anti-virus en-gines.

  • A component that is used to configure domains for serving exploits and which checks the domains for potential detection or flagging by anti-virus engines.

Listing 1 shows the basic structure of the Beta BEP that was configured on the C&C server.

http://<beta_cpanel.com>:8092/SDDS/private/panel.php?section=stats

http://<beta_cpanel.com>:8092/SDDS/private/panel.php?section=files

http://<beta_cpanel.com>:8092/SDDS/private/panel.php?section=domains 

http://<beta_cpanel.com>:8092/SDDS/private/panel.php

Listing 1: Beta BEP C&C structural components.

Target domain scanning

Beta BEP has a built-in functionality for determining the effectiveness of the domain that is used to deploy the exploit or executable which is served to the victim’s machine during an attack. When a vulnerability is found and an exploit successfully executed, the infected domain is queried in order to download the malicious executable. Beta BEP uses Scan4You [6], which is a freely available service that will check the robustness of a target domain (hosting exploits or malicious executables) against various anti-virus engines to verify its rate of detection. The idea is to check up front whether or not the configured exploit URL can be detected as malicious. Avoiding exposure to detection solutions is important in order for the malware to be served in a stealthy manner. If the target domain is found to be included on blacklists or flagged as malicious, a new one can easily be configured by the Beta BEP controller in order to continue the infection spreading mechanism. Figure 1 and Figure 2 show how Beta BEP scans the target URLs and domains to verify their detection rate by various security vendors.

Target domains are tested against the Scan4You service.

Figure 1. Target domains are tested against the Scan4You service.

Beta BEP domain-scanning component.

Figure 2. Beta BEP domain-scanning component.

The structure of the exploit-serving URLs is presented in Listing 2.

http://www.example.com:8092/776576YTU76876867HYTUYTUYTUYHYTUYHTFY/drgdrfydtuytygtryfgtrfgtrfg.php

http://www.example.org:8092/776576YTU76876867HYTUYTUYTUYHYTUYHTFY/drgdrfydtuytygtryfgtrfgtrfg.php

http://example.co.vu:8092/776576YTU76876867HYTUYTUYTUYHYTUYHTFY/drgdrfydtuytygtryfgtrfgtrfg.php

Listing 2: Structure of exploit-service URLs.

Part of the URL uses an encoding scheme, but we are not sure what type of encoding is used. Incorporating obfuscated strings into URLs is a technique commonly used by BEPs in order to bypass certain detection solutions. Figure 3 shows one of the configured domains being tested for maliciousness using the Scan4You service.

Scan4You service in action.

Figure 3. Scan4You service in action.

Malicious executable scanning

Beta BEP allows only one file at a time to be uploaded to the C&C, which then gets compressed and embedded in the required exploit. At this point, it seems that multiple malware files are not supported: if the malicious executable needs to be replaced, the previous executable (or binary) file must be deleted and cleaned in order to provide a clean environment for the new executable to be incorporated into the exploits. Like the exploit-serving URLs, the uploaded malware executable is scanned to check its rate of detection by anti-virus engines. Figure 4 shows the file uploading and scanning functionality of Beta BEP.

File uploading and scanning capability in Beta BEP.

Figure 4. File uploading and scanning capability in Beta BEP.

Exploits for specific vulnerabilities

Table 1 shows the exploits that are supported by Beta BEP as part of its design. There is the possibility for more exploits to be added and/or existing exploits removed later on. As can be seen from the CVEs, Flash exploits are preferred. This is because of the recent rise in the number of remote code execution vulnerabilities in Flash.

S. No.CVEsDescription
1CVE-2015-0311Unspecified vulnerability in Adobe Flash Player through 13.0.0.262 and 14.x, 15.x, and 16.x through 16.0.0.287 on Windows and OS X and through 11.2.202.438 on Linux allows remote attackers to execute arbitrary code via unknown vectors.
2CVE-2015-0359Double free vulnerability in Adobe Flash Player before 13.0.0.281 and 14.x through 17.x before 17.0.0.169 on Windows and OS X and before 11.2.202.457 on Linux allows attackers to execute arbitrary code via unspecified vectors.
3CVE-2015-0313Use-after-free vulnerability in Adobe Flash Player before 13.0.0.269 and 14.x through 16.x before 16.0.0.305 on Windows and OS X and before 11.2.202.442 on Linux allows remote attackers to exe-cute arbitrary code via unspecified vectors.
4CVE-2014-0556Heap-based buffer overflow in Adobe Flash Player before 13.0.0.244 and 14.x and 15.x before 15.0.0.152 on Windows and OS X and before 11.2.202.406 on Linux, Adobe AIR before 15.0.0.249 on Windows and OS X and before 15.0.0.252 on Android, Adobe AIR SDK before 15.0.0.249, and Adobe AIR SDK & Compiler before 15.0.0.249 allows attackers to execute arbitrary code via unspecified vectors.
5CVE-2014-6332OleAut32.dll in OLE in Microsoft Windows Server 2003 SP2, Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allows remote attackers to execute arbitrary code via a crafted website, as demonstrated by an array-redimensioning attempt that triggers improper handling of a size value in the SafeArrayDimen function, a.k.a. ‘Windows OLE Automation Array Remote Code Execution Vulnerability’.
6CVE-2012-1876Microsoft Internet Explorer 6 through 9, and 10 Consumer Preview, does not properly handle objects in memory, which allows remote attackers to execute arbitrary code by attempting to access a nonexistent object, leading to a heap-based buffer overflow, a.k.a. ‘Col Element Remote Code Execution Vulnerability’.

Table 1. Exploits provided in Beta BEP 3.0.

Infection statistics

We know that most crimeware service providers rent out BEPs to collect money based on successful pay-per infections (PPI). However, BEPs can also be sold directly for a lump sum. We found that Beta BEP collects the following statistics:

  • Information about compromised browsers

  • Details of the countries in which successful infections have triggered, which means that geo-location tagging is enabled in Beta BEP

  • Numbers of successful infections (or exploited end-user machines), hit rate and so on.

Figure 5 shows a snapshot taken from the Beta BEP deployment.

Beta BEP stats panel.

Figure 5. Beta BEP stats panel.

Conclusion

As we have discussed, Beta BEP is not as active in the real market as, for example, Fiesta or Angler, but we believe that we will start to see it being used in the coming months. We were not able to collect enough data to dissect the network-level details of the BEP and understand how exactly the exploits are served, but we believe that revealing as much information as we know about Beta BEP will benefit the security research community, making researchers aware of the upcoming threat so that appropriate defences can be designed and put in place to combat it.

Bibliography

[1] Browser Exploit Packs – Death with Bundled Exploits. http://www.virusbtn.com/pdf/conference/vb2011/VB2011-Sood-Enbody.pdf.

[2] What are browser exploit kits up to? A look into Sweet Orange and ProPack. https://www.virusbtn.com/virusbulletin/archive/2013/03/vb201303-SweetOrange-ProPack.

[3] Styx Exploit Pack: Insidious Design Analysis. https://www.virusbtn.com/virusbulletin/archive/2013/09/vb201309-Styx.

[6] Scan4You. http://scan4you[.]net.

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest articles:

VB2017 paper: Walking in your enemy’s shadow: when fourth‑party collection becomes attribution hell

Attribution is complicated under the best of circumstances. Sparse attributory indicators and the possibility of overt manipulation have proven enough for many researchers to shy away from the attribution space. And yet, we haven’t even discussed the…

Throwback Thursday: CARO: a personal view

As a founding member of CARO (Computer Antivirus Research Organization), Fridrik Skulason was well placed, in August 1994, to shed some light on what might have seemed something of an elitist organisation, and to explain CARO's activities and…

VB2016 paper: Uncovering the secrets of malvertising

Malicious advertising, a.k.a. malvertising, has evolved tremendously over the past few years to take a central place in some of today’s largest web-based attacks. It is by far the tool of choice for attackers to reach the masses but also to target…

VB2016 paper: Building a local passive DNS capability for malware incident response

Many security operations teams struggle with obtaining useful passive DNS data post security breach, and existing well-known external passive DNS collections lack complete visibility to aid analysts in conducting incident response and malware…

Throwback Thursday: Tools of the DDoS Trade

In September 2000, Aleksander Czarnowski took a look at the DDoS tools of the day.


Bulletin Archive