VB2018 paper: From Hacking Team to hacked team to...?

Filip Kafka

ESET, Slovakia

Copyright © 2018 Virus Bulletin



Hacking Team first came under the spotlight of the security industry following its damaging data breach in July 2015. The leaked data revealed several zero-day exploits being used and sold to governments, and confirmed suspicions that Hacking Team had been doing business with oppressive regimes. But what happened to Hacking Team after one of the most famous hacks of recent years?

Hacking Team's flagship product, the Remote Control System (RCS), was detected in the wild at the beginning of 2018 in 14 different countries, including some of those that had previously criticized the company's practices. In this paper, we will present the evidence that convinced us that the new, post-hack Hacking Team samples can be traced back to a single group – not just any group, but Hacking Team's developers themselves.

Furthermore, we will share previously undisclosed insights into Hacking Team's post-leak operations, including the targeting of diplomats in Africa, uncover the digital certificates used to sign the malware, and share details of the distribution vectors used to target the victims. We will compare the functionality of the post-leak samples with that of the leaked source code. To help other security researchers, we'll provide tips on how to efficiently extract details from these newer VMProtect-packed RCS samples. Finally, we will show how Hacking Team sets up companies and purchases certificates for them.



Since being founded in 2003, the Italian spyware vendor Hacking Team has gained notoriety for selling surveillance tools to governments and their agencies across the world. The capabilities of its flagship product, the Remote Control System (RCS), include extracting files from a targeted device, intercepting emails and instant messaging, as well as remotely activating a device's webcam and microphone. The company has been criticized for selling these capabilities to authoritarian governments [1] – an allegation it has consistently denied.

When Hacking Team itself suffered a damaging hack in July 2015 [2], the reported use of RCS by oppressive regimes was confirmed [3].

The 400GB of leaked internal data included:

  • the spyware source code
  • the spyware for different platforms
  • five zero-day exploits: 1x Windows LPE, 3x Adobe Flash, 1x Adobe Reader
  • a UEFI rootkit
  • evidence of selling an injection proxy for performing various MitM attacks
  • the once-secret list of customers
  • the pricelist
  • internal communications

Due to the severity of the leak, Hacking Team was forced to ask its customers to suspend all use of RCS, and was left facing an uncertain future.

The security community has been keeping a close eye on the company's efforts to get back on its feet. With both the source code and a ready-to-use builder leaked, it came as no surprise when cybercriminals started reusing the spyware. This was the case in January 2016, when Callisto Group reused the source code in one of their campaigns [4]. Recent reports have revealed that in June 2016, Hacking Team received funding from a mysterious investor with ties to Saudi Arabia [5].


Discovery of post-leak samples

In the early stages of our investigation, the Citizen Lab provided us with RCS samples used in 2016 and 2017, which led to the discovery of a version of the spyware currently being used in the wild and signed with a previously unseen valid digital certificate.

Our further research uncovered several more samples of Hacking Team's spyware created after the 2015 hack, all being slightly modified compared to variants released before the source code leak.

The samples were compiled between September 2015 and October 2017. We have deemed these compilation dates to be authentic, based on ESET telemetry data indicating the appearance of the samples in the wild within a few days of those dates.


Unpacking the samples

All the samples are packed with VMProtect, a commercial anti-piracy protector, which was also the case with pre-leak samples. We notified VMProtect's developers and asked them to blacklist the licence used to pack spyware, but no action was taken.

In this section, we will explain how we unpacked the samples of modified Hacking Team spyware.


Extracting details from the VMProtect-packed samples

There are two approaches – the first is intended to extract only some (valuable) details from the sample, such as the C&C; the second approach is to fully unpack the sample, including rebuilding the IAT (Import Address Table). The first approach is obviously easier and quicker, but to be able to fully analyse the samples, the second approach is needed.


First approach

For the first approach, the sample is run and after some time, when the sample unpacks itself, the process is dumped. Then the C&C or other information can be searched for in the dump. Indeed, this is not a sophisticated method, but it is important to mention this easy but still effective approach. For dumping you can use:

  1. Hacking Team's VMProtect dumper – a simple tool developed by Hacking Team's developers, which runs the VMProtect-packed sample and dumps the process memory a few times after the sample unpacks itself.
  2. Any of your favourite memory-dumping tools.


Second approach

The second approach represents typical unpacking, and results in a fully working unpacked PE file. We unpacked the sample dynamically (i.e. by executing it).

This approach includes the following steps:

  1. Run the sample and find the OEP (Original Entry Point).
  2. If imports (calls to API) are wrapped, figure out the real API function and rewrite the wrapped call.
  3. Dump and rebuild imports with typical tools.

The steps explained in detail:

    1. As VMProtect users can choose various protection settings, including detection of virtual machine or debugger, the difficulty of this part depends on what protection settings are used. We will first explain how to do the unpacking when the protection is not set to detect a debugger or a virtual machine, then we will extend our approach to bypass those detections.
      1. Run the sample inside the debugger. After some time, pause it. Then search in the memory for:
          1. Typical MSVC entry point. Programs compiled with Microsoft Visual Studio have very common code on startup, so looking for 'magic bytes' in the initialization of the security cookie (Figure 1) is enough to identify the OEP. Once the OEP has been identified, place a hardware breakpoint on the address and run the packed sample once again until it pauses at the OEP.
          2. If it wasn't compiled with Microsoft Visual Studio, or it is still somehow masquerading, it is necessary to search for the code belonging to the original application.
      2. If the protection is set to detect a debugger, it is necessary to use dumping tools as explained before, because there are no plug-ins available to successfully hide a debugger from VMProtect.
    2. Once the OEP is found, there might still be a problem with API functions – usually, VMProtect puts a 'wrapper' on them. This means that it won't call APIs directly, but instead it calls code in the .vmp section which computes the address of the API, pushes it on the stack, and finally returns to it. This wrapper makes work more difficult for typical IAT rebuilders. In order to get rid of the wrapper, it is necessary to solve the address of the API and then rewrite the wrapped call to the real address of the API. Solving the address of the API can be done either by emulation or by execution until it returns from the .vmp section to the section with imports (usually the address starts with 0x7f....).
    3. When the OEP is found and imports are in the original form without the wrapper, the process can be dumped and the IAT rebuilt using typical tools like OllyDump, Scylla or ImpRec.

Figure 1 part 1.pngFigure 1 part 2.pngFigure 1: Typical bytes on entry point in programs compiled with Microsoft Visual Studio.


Analysis of the post-leak samples

Distribution and targets

As for the distribution vector of the post-leak samples we analysed, in at least two cases, we detected the spyware in an executable file disguised as a PDF document. The names of the files suggest the malware was spread via spear-phising emails sent to high-profile targets such as diplomats:

  • 'Requirement for Diplomatic Passport Service.pdf.t.exe'
  • 'Note Verbale No 00023AM-ADD2017 du 17 janvier 2017 .exe'
  • 'Petition 2017 rasdt.......................................................................................................................................................................t.exe'
  • 'rawshi nawaxoy harim kurdstan.exe'

Our systems have detected these new Hacking Team spyware samples in 14 countries. We choose not to name the countries in order to prevent potentially incorrect attributions based on these detections, since the geo-location of the detections doesn't necessarily reveal anything about the origin of the attack.


Architecture and functionality

The malware has two stages – Scout (first stage) and Soldier or Elite (second stage; regular and premium version). The second stage, the actual payload, is deployed after a few initial checks carried out by Scout.

In the post-leak samples we analysed, Scout and Soldier had the following functionality:

Scout (version 28):

  • Installs itself, checks if other instances are already running
  • Performs AV-bypassing tricks
  • Collects basic information about the computer
  • Checks for possible upgrades of itself / Soldier / Elite

Soldier (version 1025):

  • Collected data is packed, encrypted and stored in the registry and later sent to the C&C server
  • Proper memory management, error handling
  • Capabilities: steal data from clipboard, steal data from social networks, steal passwords and other data from browsers, take screenshots, activate camera, determine geolocation based on Wi-Fi networks, record Skype calls, record keystrokes, monitor mouse clicks, schedule uninstallation of itself
  • Example of a configuration embedded in the file:



Further analysis led us to conclude that all the analysed post-leak samples can be traced back to a single group, rather than being isolated instances of diverse actors building their own versions from the leaked Hacking Team source code.



One indicator supporting this is the sequence of digital certificates used to sign the samples – we found six different certificates issued in succession. Four of the certificates were issued by Thawte to four different companies, and two are personal certificates issued to Valeriano Bedeschi (Hacking Team co-founder) and someone named Raffaele Carnacina.

Figure 2.pngFigure 2: The sequence of digital certificates used to sign the post-leak samples. Samples signed by Valeriano Bedeschi were most likely used for testing purposes, as the C&C was set to an internal network (



The versioning observed in the analysed samples continues where Hacking Team left off before the breach, and follows the same patterns. Hacking Team's habit of compiling Scout and Soldier consecutively, and often on the same day, can also be seen across the newer samples.

Figure 3 shows the compilation dates, versioning and certificate authorities of Hacking Team Windows spyware samples seen between 2014 and 2017. Post-leak samples with renewed versioning begin with the sample signed by Valeriano Bedeschi. Reuse of the leaked source code by Callisto Group is marked in red.

Figure 3.pngFigure 3: Hacking Team Windows spyware samples seen between 2014 and 2017.


Modifications in line with Hacking Team development habits

Furthermore, our research has confirmed that the changes introduced in the post-leak updates were made in line with Hacking Team's own coding style. The changes are often found in places that indicate a deep familiarity with the code, and follow Hacking Team's previously established development patterns (visible in the leaked source code).

Other than these specific changes, the majority of the code is without any modifications. It is highly improbable that some other actor – that is, other than the original Hacking Team developer(s) – would make changes in exactly these places when creating new versions from the leaked Hacking Team source code.

1. Difference in Scout Startup file size

As shown in Figure 4, one of the subtle differences between the pre-leak and post-leak samples is a difference in Startup file size. When Scout installs on the system, it copies itself into the Windows Startup folder and appends random data to the end of the binary. This trick was used as an evasive technique against one anti-virus product. Before the leak, the copied file was padded to occupy 4MB. In the post-leak samples, this file copy operation is padded to 6MB.

Figure 4.pngFigure 4: Startup file size copy changed from 4MB pre-leak to 6MB post-leak.

2. Improved random number generation

Scout samples from before the leak used the GetTickCount and Rand functions to generate random numbers for increasing their size by appending the numbers at the end of the binary. In the post-leak samples, the number generation has been improved by using the CryptGenRandom API function. Only if this function fails are the previous functions used.

3. Changes in MySleep function

Hacking Team developers used their own MySleep function – in the samples from before the leak, it was implemented for bypassing sleep patches in many sandboxes. It consisted of the GetCurrentThread and WaitForSingleObject Windows API functions. In the post-leak samples, the MySleep function is still present, but now comprises the CreateEvent, WaitForSingleObject and CloseHandle Windows API functions.

4. Change in fake error message strings

The pre-leak samples contain fake error message strings to be used in case the spyware is run with a system process ID (i.e. 0 or 4). A process executed by a regular user would never have these ID values, so this trick might be aimed at sandboxes or emulators.

The content of the fake error messages had been changed regularly before the leak; the history of these changes was revealed in the leaked source code (Figure 5).

Figure 5.pngFigure 5: Fake strings history in the Scout leaked source code. RCS 9.5 includes Scout versions 11 and 12.

In the post-leak samples, the strings have been changed again, this time to the message 'Aborting now'.

5. Change in user agents

Compared to pre-leak samples, some of the parameters of the user-agent string used for HTTP protocol when communicating with the C&C server are different in the newer samples. (See Figures 6 to 10.)

Figure 6.pngFigure 6: User-agent string history in the Scout leaked source code. RCS 9.4 includes Scout version unknown; RCS 9.5 includes Scout versions 11 and 12.


Figure 7.pngFigure 7: Altered user-agent string in Scout version 15.


Figure 8.pngFigure 8: Altered user-agent string in Scout version 17.


Figure 9.pngFigure 9: Altered user-agent string in Scout version 22.


Figure 10.pngFigure 10: Altered user-agent string in Scout version 28.

6. Changes in strings used for C&C sync

The URL path used for HTTP protocol when communicating with the C&C server is another part of the code that was frequently changed in the pre-leak samples. In the post-leak samples, these paths also vary from sample to sample.

Figure 11.pngFigure 11: Strings used from C&C sync in the Scout leaked source code. RCS 9.4 includes Scout version unknown.; RCS 9.5 includes Scout versions 11 and 12.


Figure 12.pngFigure 12: Alter URL Sync string in Scout version 15.


Figure 13.pngFigure 13: Alter URL Sync string in Scout version 17.


Figure 14.pngFigure 14: Alter URL Sync string in Scout version 18.


Figure 15.pngFigure 15: Alter URL Sync string in Scout version 28.



None of these indicators, by themselves, represents conclusive evidence of Hacking Team's renewed activity. However, viewing them as a whole lets us claim with high confidence that, with one obvious exception, the post-leak samples we've analysed are indeed the work of the Hacking Team developers, and not the result of source code reuse by unrelated actors, such as in the case of Callisto Group in 2016.



[1] The Citizen Lab. Mapping Hacking Team's "Untraceable" Spyware. February 2014. https://citizenlab.ca/2014/02/mapping-hacking-teams-untraceable-spyware/.

[2] Franceschi-Bicchierai, L. Spy Tech Company 'Hacking Team' Gets Hacked. Motherboard. July 2015. https://motherboard.vice.com/en_us/article/gvye3m/spy-tech-company-hacking-team-gets-hacked.

[3] Hern, A. Hacking Team hacked: firm sold spying tools to repressive regimes, documents claim. The Guardian. July 2015. https://www.theguardian.com/technology/2015/jul/06/hacking-team-hacked-firm-sold-spying-tools-to-repressive-regimes-documents-claim.

[4] F-Secure Labs. Callisto Group. April 2017. https://www.f-secure.com/documents/996508/1030745/callisto-group.

[5] Franceschi-Bicchierai, L. Hacking Team Is Still Alive Thanks to a Mysterious Investor From Saudi Arabia. Motherboard. January 2018. https://motherboard.vice.com/en_us/article/8xvzyp/hacking-team-investor-saudi-arabia.

Download PDF



Latest articles:

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Dissecting the design and vulnerabilities in AZORult C&C panels

Aditya K Sood looks at the command-and-control (C&C) design of the AZORult malware, discussing his team's findings related to the C&C design and some security issues they identified during the research.

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.