Award-winning news, views, and insight from the ESET security community

New traces of Hacking Team in the wild

Since being founded in 2003, the Italian spyware vendor Hacking Team 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.

Since being founded in 2003, the Italian spyware vendor Hacking Team 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.

Previously unreported samples of Hacking Team’s infamous surveillance tool – the Remote Control System (RCS) – are in the wild, and have been detected by ESET systems in fourteen countries.

Our analysis of the samples reveals evidence suggesting that Hacking Team’s developers themselves are actively continuing the development of this spyware.

From Hacking Team to Hacked Team to…?

Since being founded in 2003, the Italian spyware vendor Hacking Team 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 – an allegation it has consistently denied.

When the tables turned in July 2015, with Hacking Team itself suffering a damaging hack, the reported use of RCS by oppressive regimes was confirmed. With 400GB of internal data – including the once-secret list of customers, internal communications, and spyware source code – leaked online, Hacking Team was forced to request its customers to suspend all use of RCS, and was left facing an uncertain future.

Following the hack, the security community has been keeping a close eye on the company’s efforts to get back on its feet. The first reports suggesting Hacking Team’s resumed operations came six months later – a new sample of Hacking Team’s Mac spyware was apparently in the wild. A year after the breach, an investment by a company named Tablem Limited brought changes to Hacking Team’s shareholder structure, with Tablem Limited taking 20% of Hacking Team’s shareholding. Tablem Limited is officially based in Cyprus; however, recent news suggests it has ties to Saudi Arabia.

Having just concluded our research into another commercial spyware product, FinFisher, two interesting events involving Hacking Team occurred in close succession – the report about Hacking Team’s apparent financial recovery and our discovery of a new RCS variant in the wild with a valid digital certificate.

The spyware lives on

In the early stages of this investigation, our friends from the Citizen Lab – who have a long record of keeping track of Hacking Team – provided us with valuable input that 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.

Further analysis led us to conclude that all the 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, as shown in the following table:

Certificate issued to

Validity period

Valeriano Bedeschi

8/13/2015 – 8/16/2016

Raffaele Carnacina

9/11/2015 – 9/15/2016

Megabit, OOO

6/8/2016 - 6/9/2017

ADD Audit

6/20/2016 - 6/21/2017

Media Lid

8/29/2016 - 8/30/2017

Ziber Ltd

7/9/2017 - 7/10/2018

The samples also have forged Manifest metadata – used to masquerade as a legitimate application – in common, appearing as “Advanced SystemCare 9 (9.3.0.1121)”, “Toolwiz Care 3.1.0.0” and “SlimDrivers (2.3.1.10)”.

Our analysis further shows that the author(s) of the samples have been using VMProtect, apparently in an effort to make their samples less prone to detection. This was also common among pre-leak Hacking Team spyware.

The connections among these samples alone could have originated with virtually any group re-purposing the leaked Hacking Team source code or installer – as was the case with Callisto Group in early 2016. We have, however, collected further evidence that ties these post-leak samples to Hacking Team’s developers themselves.

The versioning (which we accessed after overcoming VMProtect protection) observed in the analyzed samples continues where Hacking Team left off before the breach, and follows the same patterns. Hacking Team’s habit of compiling their payloads – named Scout and Soldier – consecutively, and often on the same day, can also be seen across the newer samples.

The following table shows the compilation dates, versioning and certificate authorities of Hacking Team Windows spyware samples seen between 2014 and 2017. Reuse of leaked source code by Callisto Group is marked in red.

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 and are often found in places indicating a deep familiarity with the code. 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.

One of the subtle differences we spotted between the pre-leak and the post-leak samples is the difference in Startup file size. Before the leak, the copied file was padded to occupy 4MB. In the post-leak samples, this file copy operation is padded to 6MB – most likely as a primitive detection evasion technique.

We found further differences that fully convinced us of Hacking Team’s involvement. However, the disclosure of these details could interfere with the future tracking of the group, which is why we choose not to publish them. We are, however, open to share these details with fellow researchers (for any inquiries contact us at threatintel@eset.com).

The functionality of the spyware largely overlaps with that in the leaked source code. Our analysis so far has not confirmed the release of any significant update, as promised by Hacking Team following the hack.

As for the distribution vector of the post-leak samples we analyzed, at least in two cases, we detected the spyware in an executable file disguised as a PDF document (using multiple file extensions) attached to a spearphishing email. The names of the attached files contain strings likely aimed to reduce suspicion when received by diplomats.

Figure 2 – Investigation timeline

Conclusion

Our research lets us claim with high confidence that, with one obvious exception, the post-leak samples we’ve analyzed are indeed the work of Hacking Team developers, and not the result of source code reuse by unrelated actors, such as in the case of Callisto Group in 2016.

As of this writing, our systems have detected these new Hacking Team spyware samples in fourteen countries. We choose not to name the countries 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.