Police Story Hacking Team’s Government Surveillance Malware

The left newspapers might whine a bit

But the guys at the station they don’t give a shit

Dispatch calls “Are you doin’ something wicked?”

“No siree, Jack, we’re just givin’ tickets”

Police Truck, Dead Kennedys (1980)

Summary

• In Part 1, we analyze a newly discovered Android implant that we attribute to Hacking Team and highlight the political subtext of the bait content and attack context.
• In Part 2, we expose the functionality and architecture of Hacking Team’s Remote Control System (RCS) and operator tradecraft in never-before published detail.

Introduction

This report analyzes Hacking Team’s Android implant, and uses new documents to illustrate how their Remote Control System (RCS) interception product works. This work builds on our previous research into the technologies and companies behind “lawful interception” malware.  This technology is marketed as filling a gap between passive interception (such as network monitoring) and physical searches.  In essence, it is malware sold to governments.  Unlike phone monitoring and physical searches, however, most countries have few legal guidelines and oversight for the use of this new power.  In light of the absence of guidelines and oversight, together with its clandestine nature, this technology is uniquely vulnerable to misuse. By analysing the tools, and their proliferation at the hands of companies like Hacking Team and Gamma Group, we hope to support efforts to ensure that these tools are used in an accountable way, and not to violate basic principles of human rights and rule of law.

In a report published earlier this year, we presented the results of a global scanning effort, and identified 21 countries with deployments of Hacking Team’s Remote Control System monitoring solution. In addition, alongside other researchers, we have uncovered a range of cases where “lawful interception” software has been used against political targets by repressive regimes. Political and civil society targets have included Mamfakinch in Morocco, human rights activist Ahmed Mansoor in the UAE, and ESAT, a US-based news service focusing on Ethiopia. In all of these cases, a tool marketed for “law enforcement” was used against political, rather than security threats.  In still other cases, like Malaysia [PDF], we have found bait documents and seeding suggestive of political targeting.

Part 1: An Android Hacking Team Backdoor in Saudi Arabia

Protests in Saudi Arabia and Qatif

While Saudi Arabia has not seen protests comparable to those elsewhere during the Arab Spring, it has experienced protests since 2011, primarily in the Ash-Sharqīyah province.  There are a number of reasons for political tensions, ranging from demographic pressures, cost of housing, and unemployment, to issues of women’s and minority rights. The province is predominantly Shia, who have long-standing grievances over perceived political and cultural marginalization by the Sunni ruling regime. These grievances were magnified when, in early 2011, the Bahraini government violently suppressed Shia protests with the assistance of Saudi Arabian troops.

Protests then spread in a number of areas, including in the predominantly Shia Qatif Governorate. In 2011, Shia most protesters appear to have initially demanded reform, rather than the regime-change advocated in other Arab countries.  Interestingly, Qatif has a history of Shia protest, most famously in widespread protests in 1979.  In response to the protests, which demanded greater political and economic participation, the regime provided extensive economic concessions.  In 2011, however, authorities responded with violence and arrests of prominent Shia figures. Protesters were wounded and others allegedly killed by security forces, according to Human Rights Watch.  This crackdown may have contributed to shifting protesters’ demands; today, some explicitly demand regime change using secular language, according to researchers and journalists directly familiar with recent developments who spoke with us.  In what might be described as an inflammatory response, Saudi authorities also arrested an outspoken and highly visible Shia Sheikh.

“… the prosecutor demanded he face not only the death sentence, but an additional punishment mandated by sharia law for the most heinous offences in which the dead body is defiled by being hanged from a pole.” –Reuters

The escalation, which has been accompanied by violence against security services among some Shia, is used by the regime to justify harsh measures, including “riot control,” arrests, and sentences including death for protesters on charges of “Sedition.”  Others have been charged with espionage on behalf of Iran, in a case that has been claimed by many Shia to have been politically motivated.

Human rights organizations that have catalogued alleged abuses, like the Adala Center for Human Rights, have been denied the ability to register as formal organizations, subject to URL blocking, and had staff harassed and imprisoned. Journalists attempting to report on Qatif are blocked from entering, and regularly subjected to threats and government pressure.

Social media and mobile phones are a key part of how protests are organized, with protesters taking measures, like using pseudonymous accounts, to share their message.  Nevertheless, according to people familiar with the events, digital operational security practices are often piecemeal, and do not match the capabilities of the security services.

Surveillance, Monitoring and Information Control in Saudi Arabia

Saudi Arabia is a unique and complex security environment, and its security services play a range of roles.  On the one hand, Saudi Arabia faces undeniable foreign and domestic security threats from hostile groups, extremists and other governments. On the other hand, the regime has been exceptionally aggressive in its attempts to control and stifle dissent and political pluralism.

The security services in Saudi Arabia make use of a range of instruments of formal and informal state power to control the electronic information environment in the country.  Beginning at government-maintained Internet chokepoints and extending to ISPs, the state blocks a wide range of political, religious and cultural content.  This includes social media, whether specific users or whole platforms.  Extending further, the state requires that news websites (defined broadly) register with the authorities.  Registered websites are subject to extensive regulation, while unregistered operators that have not registered risk severe penalties.  Site operators are encouraged to self-monitor and moderate content, under threat of financial penalties, jail time, and corporal punishment like lashes.  In addition, anti-cybercrime legislation has also been used to prosecute online dialogue that most societies would consider acceptable political speech.

The public use of mobile monitoring extends into forms of social control that many societies would find highly objectionable.  For example, the government earned international condemnation when it announced that it would implement a system to enable their male guardian to monitor the travel behavior of women under their care.  Replacing an older permission-slip based system (“yellow cards”), male guardians receive text messages when women arrive on the premises of the international airport, asking whether the women are permitted to travel.

Internet and social media users are encouraged to self-censor and report on each other.  The government engages in public advertising campaigns to encourage both behaviours, and makes it clear to Saudi citizens that they are watching, and listening.  In particular, the state has implemented specific penalties for re-sharing, privately or publicly, content deemed objectionable.  In addition to using the explicit tools of the law, it is widely believed that the state encourages an “electronic army” of pro-government individuals to swamp social media conversations with pro-regime voices and harass dissenters.

Speech involving religious themes is especially risky, as the government is willing to use serious religious charges, including the death penalty and corporal punishment, and tools of international jurisprudence like extradition, to detain and punish those who violate its strict norms for political, religious, and cultural speech.

In two notable cases, the operator of the Saudi Liberals discussion forum was eventually sentenced to 10 years in prison and 1000 lashes for maintaining a forum on the discussion of religion and reform.  This was a reduction of sorts, as the prosecution demanded his execution.  Many similar cases, using various charges, have been reported by human rights organizations and commentators.

These measures have an intentionally chilling effect on political speech, and are regularly the subject of criticism by the international human rights community.  Nevertheless, social media remains the primary outlet for political speech.  Many users practice some degree of self censorship, or indirect speech, while others use pseudonyms and other technical means to preserve their anonymity.   To access banned content, the use virtual private networks (VPNs) is also common. In response, security services use police and investigative powers to unmask the posters, and punishes them severely, sometimes after arrests where the name of the detainee(s) is kept secret.

Phone use in Saudia Arabia has a penetration rate of 170%, with an estimated average of 30% of individual income spent on mobile phone and Internet costs in 2014.  As a result, older mechanisms of Internet surveillance, like monitoring Internet cafes, are being replaced.  Individual users are required to use real identities when registering mobile devices, and it is clear that the state is seeking greater visibility into encrypted traffic. In 2010, for example, Saudi Arabia successfully gained access to BlackBerry communications after making Saudi-located servers a quid-pro-quo of allowing the devices on Saudi Networks.  More recently, the government’s appetite for encrypted communications was revealed by Moxie Marlinspike, a security researcher and developer, who received an overture from Saudi telecom company Mobily seeking his assistance in accessing encrypted traffic.  The firm was seeking an intercept solution (on request of the Saudi Government, they said) for access to a range of mobile chat clients (Viber, LINE, WhatsApp) as well as the mobile-version of Twitter.

The use of mobile malware can be understood as part of this desire, by no means limited to Saudi Arabia, to match the technologies in use by their population.

Seeding: A Lure with Political Subtext?

Using signatures developed as part of our ongoing research into “lawful intercept” malware developed by Hacking Team, we identified a suspicious Android installation package (APK).  The file was a functional copy of the ‘Qatif Today’ (القطيف اليوم) news application bundled with a Hacking Team payload.  Documents we have reviewed suggest that Hacking Team refers to this kind of mobile implant as an “Installation Package,” where a legitimate third party application file is bundled with the implant (See: Developing and Deploying Implants). This kind of tactic with Android package implants has been seen in other targeted malware attacks (that do not use commercial “lawful intercept” products) including the LuckyCat campaign, and in attacks against Tibetan activists, and groups in the Uyghur community.

The genuine ‘Qatif Today’ app is an Android (download here) and iPhone application that provides news and information in Arabic with a special relevance to the Qatif Governorate of Saudi Arabia.

The connection to Qatif is interesting, given the recent history of protest in Qatif as outlined above.  We are not in a position to determine the identity of the group or individual targeted with this malware, however, we speculate that the attack may be linked to political protest in eastern Saudi Arabia.

Hacking Team Samples

The malicious APK, QatifNews.apk, has the following hash:

At the time of first submission to the VirusTotal database, the file was detected by zero out of 50 AntiVirus products in VirusTotal:

It appears that an APK of the same name was seeded on Twitter 5 days later by a Twitter account (@_bhpearl)  linked to Bahrain, a country of great interest to Shia in Qatif.

The tweeted links were shortened using the goo.gl service. These resolved to:

and

The first link to the iTunes store has 18841 clicks on the shortened link and appears legitimate. The second link, however, does not redirect to the genuine app at the Android App Store. Instead, it redirects to a Dropbox file that has since been removed. Examination of analytics on the shortened second link is interesting; there were only 13 clicks. We can discount 7 of these clicks (those in US and Germany) as researchers, while three are in Saudi Arabia. One click in Taiwan may be a VPN, or a security researcher.

While we cannot confirm that the file on Dropbox was the same APK, we suspect the timing of the tweet, and the use of a non-standard method for sharing an Android application,  is not a coincidence.

Malicious APK Code Signing

The malicious apk was signed by the following certificate:

A broader discussion of code-signing practices for Hacking Team implants is discussed later in the document in the section “Code Signing and Certificates”.

Additional Samples

We were able to identify an additional six samples signed with the same certificate:

The first sample of this list (…db4) was submitted to VirusTotal as:

Interestingly, this was the first sample (chronologically) to be submitted to VirusTotal from this group of files. The name “rcs.apk” appears to be an abbreviation of the name of Hacking Team’s targeted surveillance solution, ‘Remote Control System.’

Permissions

The original app requires the following permissions:

The implant requests the following permissions, which give it the ability to process calls, read and write SMS messages, monitor the user’s GPS location, and more.

The following permission was requested by several of the other identified Hacking Team android implants:

This value allows applications to change the APN (Access Point Name), a setting on a mobile phone that identifies an external network the phone can access for data. This value is marked as not for use by third party applications in the Android Developers reference.¹  For further discussion of this functionality, see: Other Capabilities.

Behavior & Network Communication

After analyzing the behavior of the application we were able to further confirm the malicious nature of the file.

When executed, the app performs a POST to:

This server is hosted at iWeb in Montreal:

IP Address	174.142.97.245
Host	server.5edma.com
Location	CA, Canada
City	Montréal, QC H3E 1Z6
Organization	IWeb Technologies
ISP	IWeb Technologies
AS Number	AS32613 iWeb Technologies Inc.

We believe this to be legitimate communication by the decoy application.

We also observed command and control (C2) communication with two additional servers.  We later found the same IP addresses in decrypted text from the implant’s config file (see: Obfuscation / Implant Configuration).  Incidentally, this was consistent with how Hacking Team implants store C2 addresses.

The first server is hosted on Leaseweb in Germany:

Host	91.109.17.189
Location	DE, Germany
Organization	Leaseweb Germany GmbH (previously netdirekt e. K.)
AS Number	AS16265 LeaseWeb B.V.

The second is hosted on Linode in Japan:

IP Address	106.186.17.60
Host	li528-60.members.linode.com
Location	JP, Japan
Organization	Kddi Corporation
AS Number	AS2516 KDDI KDDI CORPORATION

In previous work, we identified both the Leaseweb and the Linode IPs as part of a Hacking Team proxy chain uncovered in our prior reporting.  At the time, we also identified a third IP (206.190.155.40) that belonged in the same group. This finding indirectly validates the methods used in the previous report, and highlights the third IP as likely part of the same collection infrastructure.

This additional IP is in a block owned by the hosting provider SoftLayer Technologies.

Rooting Exploit

The malicious implant attempts to stat() the following files:

This behavior is consistent with a known exploit (CVE-2012-6422) that permits a user without permissions to write to a compromised device’s physical memory.  An in depth analysis of this exploit is provided by Azimuth Security here.

While this exploit would not be effective against the latest version of the Android operating system, a high percentage of users still use legacy versions which may be vulnerable.²

Background on Rooting Android Devices

Rooting an Android phone typically involves two components: the su binary and a supervisor application.

In order to install the su binary, either the device manufacturer has allowed the boot loader to be unlocked or a vulnerability is exploited to temporarily elevate permissions. Once the su binary is installed, applications may use it in a controlled way to elevate their permissions for other purposes.

The su is much like the traditional Unix – it uses the suid flag so applications that call it elevate their permissions to that of the executable they are calling – in most cases, including this one, root. Each application on Android is run by its own user in order to prevent applications from accessing resources it does not have permissions for.

A supervisor application (usually Superuser.apk) is used by people who intentionally root their phone so the su binary can call the supervisor which will then notify the user and allow them to approve or deny the privilege escalation. Thus, even with a rooted phone the user is still notified when applications perform actions requiring root access.

How this applies to the RCS Android Implant

In this case a vulnerability is exploited to initially gain root access, and a binary is dropped. It copies itself to /system/bin/rilcap (through /proc/self/exe) and sets its owner to be root as well as setting the executable and suid flags. This allows for persistent root access.

RILCAP Functionality

Examination of the binary revealed that basic techniques such as simple encryption of strings are used to hinder analysis.

Encryption algorithm:

The binary contains the following functionality:

• Capture information from the framebuffer (/dev/graphics/fb0) — which can then be used to assemble screenshots
• Kill the volume daemon (which automatically detects and mounts storage devices when added)
• Mount /system as read only or read write
• Check /proc/mounts for an sdcard
• Execute commands from unprivileged applications using system()
• Execute commands from a file using execv /system/bin/sh
• Modify /data/system/device-policies.xml to add the application as device admin
• Copy files
• Modify file permissions
• Change file owners
• Unlink self
• Restart the device

This functionality allows RILCAP to act as the su binary would — only there is no supervisor application to notify the user of privilege escalation and offer the choice to allow or deny it.

A full list of of commands can be found in Appendix B.

Functionality

Looking at the samples as a group, we identified a range of behaviors indicative of the implant’s surveillance capabilities.

Attempts to access 3rd party chat / voice apps:

We found that the apps attempt to access the local files stored by popular social media, chat, and call apps including Facebook, Viber, WhatsApp, Skype, LINE and QQ.

In addition, the app accesses the locally stored mail files belonging to the compromised user’s mail account.

Obfuscation / Implant Configuration

In order to prevent additional scrutiny into the internals of the backdoor, the source code appears to have been heavily obfuscated through the use of DexGuard (0r similar), which can provide encryption for strings, entire classes and assets, considerably slowing and complicating the reverse engineering process.

While analyzing the implant, we de-obfuscated the configuration file. Below, we highlight a number of lines that match functionality in RCS (for a more complete list see: Implant Modules and Functionality).

We find a range of audio recording, camera, video, key logging, “live mic,” chat, device info etc. configuration settings relevant to the surveillance functionality of the implant.  We also note the presence of a “crisis” module, which provides anti-analysis functionality explained below (see: Anti-Analysis Functionality & Anti Forensics).

We also see what appear to be, location, screenshot-taking, and browsing activity modules.

We also found that the implant seems to have been deployed with a filter to specify a date range (“datefrom” and “dateto” for the Mail, SMS and MMS messages it is seeking.

We also see information about how the implant exfiltrates data, along with its C2 servers. Interestingly, it appears that the implant is capable of monitoring the devices connectivity (e.g. wifi, cellular network), choosing connection type, and rate limiting the bandwidth.  Note that these are the same servers we observed in the implant’s network communications.

Part 2: Hacking Team RCS Operation

After we released our research on Hacking Team earlier this year, we were sent documentation by an anonymous individual pertaining to the set up and operation of Hacking Team’s RCS that Hacking Team provides to its customers.  The documents appear to date from fall 2013.  We have no knowledge as to the origin of the documents, and whoever sent them took steps to conceal their identity.  While the authenticity of these documents is unverified, we have not identified inconsistencies with what is currently known about Hacking Team RCS (our latest findings included).  We are concerned, however, that releasing the documents in their full form could bring risk to the source.  The following is thus a general overview of some of the functionality and specifics of the Remote Control System, according to these documents. The screenshots that we excerpt are clearly from instances marked as “Demo” copies, rather than actual operations.

Architecture of a Hacking Team RCS Deployment

The following image suggests the logical architecture of a prototypical Hacking Team RCS deployment.  In specific instances, according to these documents, a “distributed” architecture can be used (see: Appendix: Distributed Hacking Team RCS Architecture).

Players in System Operation

According to the documents, RCS has a series of defined roles, each with their own responsibilities and permissions on the system.  In brief:

• A System Administrator appears to receive training from Hacking Team during the “Contract Phase”, as well as other system administration tasks, including installing and updating RCS server networks as well as network injectors.
• An Administrator creates accounts, and creates both operations and designates targets.
• A Technician is responsible for creating implants (named “agents” in the documentation) and managing network injectors.
• Analysts handle outputs from the system and perform intelligence analysis via the RCS console.

Developing and Deploying Implants

According to the documents, the software can create a full range of implants through a “factory” which is compiled specifically for an investigation. The Technician is responsible for creating these agents using the “factory.”  Here is the prompt presented to the Technician:

The technician has a range of options from the Factory as well as the additional ability to use Network Injection (not pictured).  These options include:

• Network Injection:  via injected malicious traffic in cooperation with an ISP
• Tactical Network Injection: on LAN or WiFi
• Melted Application: bundling a Hacking Team dropper alongside a bait application
• Installation Package: a mobile installer
• Exploit: document-based exploit for mobile and desktop
• Local Installation: mobile installation via USB or SD card
• Offline Installation: create an ISO for a bootable SDHC, CD, or USB. This option includes the ability to infected hibernated and powered off devices
• QR Code:  a mobile link that, when pictured, will infect the target
• Applet Web: likely a malicious website (depreciated after v. 8.4)
• Silent Installer: a desktop executable that will install the implant
• Infected U3 USB: an auto-infecting U3 USB
• WAP Push Message: the target will be infected if the user accepts the message (works on all mobile operating systems apart from iOS)

Infection: “Scout Agents” and “Agents”

The documents indicate that RCS makes use of a “scout agent,” commonly known as a “validator” that helps to determine whether a full implant (“agent”) should be installed. This thin implant collects screenshots and device information to determine whether the target is of interest.

The documents suggest that Hacking Team is explicitly concerned with the possibility that their implant could become unmasked, and instructs technicians that a function of “scout agents” is to determine whether the system is ‘safe’ to infect, or whether it could risk unmasking the agent.

When the system is determined to be safe to infect, the “scout agent” is replaced by the full implant. According to the documents, Hacking Team advises users to gradually add functionality to implants. These implants exfiltrate data and receive instructions through a process called “synchronizing.”

Implant Modules and Functionality

The implant (“agent”) offers one-click functionality for requesting information from target devices. Technicians are encouraged to add functionality as needed.

In addition, a more advanced approach can be taken, allowing a sophisticated technician to determine a specific sequence of module activation upon infection, using a graphical flow model. This allows the user to define events that trigger particular actions, sub-actions, modules, and sequences.

The documents provide an example of such a sequence:

Selection of available surveillance modules

Other Capabilities

Once an implant is operational its collection operations can be updated. In addition files can be sent to and received from the device.

In addition, implants have a default cap on “evidence” space of 1GB on the target device. Recording of new material stops when the space is reached. Operators also have the ability to delete not-yet-transmitted data on the device.

Synchronizing & Data Exfiltration

The synchronizing process has a number of steps, paraphrased here:

• Authorization between implant and server
• Time syncing between implant and RCS server
• Implant removal (if case specified as “closed” by technician)
• Implant configuration update
• Implant downloads material sent from the RCS server
• Upload to RCS server of “download” cue material
• Upload to RCS server of evidence, combined with secure delete
• Additional secure deletion of evidence

Mobile and desktop versions have slightly different parameters. While desktop implants can have bandwidth and delays in sending materials added, the mobile settings have some unique features.

Technicians can force the type of data channel (WiFi or Cell Network) that the implant uses to update. Interestingly, technicians can specify login credentials for the APN used to exfiltrate data. This allows the implant to avoid incurring data charges and displaying traffic to the victim. The feature is specified as only available on BlackBerry and Symbian OS in Version 9 of RCS.

Anti-Analysis Functionality & Anti Forensics

A functionality referred to as “crisis” allows for actions on detection of “hostile” activity (the documents give the example of a packet sniffer). This functionality can be triggered by a range of scenarios and have a number of options based on identifying processes. In desktop versions, these options can including pausing synchronizing, and not hooking programs. For mobile versions these options includes pausing audio, camera, location collecting, and synchronizing.

A wipe can also be triggered, and according to the documents, Hacking Team informs users that it will leave “no trace” of the implant. The uninstall action has several features that could be of interest in forensic analysis of potentially infected devices: (i) uninstall on BlackBerry triggers an automatic restart; (ii) uninstall on Android devices where root was not successfully gained results in a user prompt requesting permission to uninstall; (iii) on Windows Phone, uninstall deletes all files but does not remove the Application Icon from the list of programs.

Code Signing and Certificates

RCS is designed to incorporate code signing when creating implants. The documents helpfully suggest Verisign, Thawte and GoDaddy as sources of code signing certificates. In addition, the documents encourage users to contact Hacking Team technical support for assistance in obtaining a certificate.

Interesingly, for Symbian, users are instructed to purchase a “Developer Certificate” directly from TrustCenter and even provides the URL (https://www.trustcenter.de/en/products/tc_ publisher_id_for_symbian.htm).

For infecting Windows Phones, users are encouraged to register a Microsoft account (signup.live.com) and a Windows Phone Dev Center account (https://dev.windowsphone.com/en-us/join/).

The documents indicate that Hacking Team is concerned with ensuring users correctly manage the approval process (managed by Symantec) and instructs users to promptly reply to phone and e-mail communications from Symantec.  Users also get instsructions in how to obtain an Enterprise Mobile Code Signing Certificate (https://products.websecurity.symantec.com/orders/enrollment/microsoftCert.do)

Android Specific Issues

In order to run some of its modules (Chat, Messages, Screenshot), the Android implant requires root privileges on the device. In some cases, where acquisition of root privileges is unsuccessful, the victim can be manually asked to give the application root access. In addition, in cases where root has not been successfully acquired on an Android device, the victim sees a prompt requesting permission if an uninstall has been triggered.

Anonymizer & Proxy Chain Architecture

This image highlights how a system administrator sees a distributed proxy chain (see: Appendix: Distributed Hacking Team RCS Architecture) and collector architecture.

Licensing, Updates

At the time of creation of a collection architecture, a license file from Hacking Team is required by the software, according to the documents. Other licenses are required for for specific functionality, as well as the more developed analysis toolkits.

The documents suggest that Hacking Team maintains an update cycle for its products. The updating process is performed by a System Administrator using updates provided by Hacking Team and includes updates both to the collection and injector infrastructure, and to implants.

Auditing

The program does appear to have a basic logging function and auditing capability, allowing authorized administrators to view logs of user actions throughout the system, including interactions with implants. This capability appears to have been developed to make the toolkit more compatible with evidence requirements for with digital material. We note however, the ease with which evidence, logs, implants, and “factories” can be irreversibly deleted by authorized users.

Analysts Eye View

This image graphically shows the ways in which multiple devices of a single target may be compromised and simultaneously monitored.

Analysts can perform searches on data using text strings as well as filtering and sorted data. In addition, Analysts can flag data for importance, as well as apply automated rules for flagging data.

Data storage makes use of the open source MongoDB, and documentation indicates that Hacking Team RCS uses MongoDB 2.4.8.

Next, also from a demo instance, we see the information exfiltrated from a target computer. Of note is the use of a basic color coded flagging system (red, green, yellow) to flag evidence, as well as the kind of information available to the analyst from each capture. Here we see screenshots of particular program operations (e.g. running BlackBerry Desktop software, and Skype) as well as location information.  Addresses in the location information are identical to the publicly available address of Hacking Team.

In the following image we see the analyst console playing back an intercepted Skype call.

In the following image, we see live browsing of an infected system’s file tree. This is a functionality that can be enabled in certain cases.

The image below shows a map and timeline view of the position of infected devices.  Interestingly, in this image, used as an instructional illustration, it appears that Hacking Team might have inadvertently revealed information about a demonstration to a US Law Enforcement to its other customers.  Specifically, the location of the “Jimmy Page” device on this map is in the access-controlled parking lot of the LA County Sheriff (and appears to be stamped with the date Sept 6 2013 or December 3 2012).  It may be coincidental that Hacking Team was extensively represented at the ISS World held later in September 2013 in the US.

The use of Google maps in the tool provides a graphic view of the targets; however it may present a serious breach of operational security for clients, including betraying location data for ongoing investigations. Even if some of the point data is not transmitted, Google needs to know the map centroid (and hence target location) to deliver some of this map data.

In addition, Google Maps traffic, even using SSL, has been subject to successful traffic analysis by third parties in the past.  While we have not demonstrated this vulnerability, we believe this possibility warrants further investigation.

Beyond collection of data, the documents indicate that Hacking Team is offering a basic investigation management toolkit including basic link analysis and other features with the purchase of an additional license.  The software can build very basic link analysis using “Peer” (contact between entities like calls) and “Know” (one or both individuals found in others phone book) links.  The system also automatically attempts to create identity links when details are shared between entities (e.g. a phone number).  Time-series and locational data can also be displayed.

Evolving Terminology

The documents suggest that Hacking Team has made a number of changes in the language it uses to describe its tools. We found for example that in v7.6 and below they used the term “Backdoor” to refer to their implant, but changed the term in v 8.0 and above to “Agent.” Similarly, they changed the term “Backdoor Class” to “Factory” in the same time period.

“Invisibility”

According to the documents, Hacking Team appears to supply customers with an “Invisibility Report” for its RCS solultion. For example, we have reviewed the “Version 9.0 – Invisibility Report” for the Silent Installer, Melted application, Network Injector INJECT-EXE attack, and Offline CD.”

The document informs customers: Tests were performed on a default 64-bit Windows 7 installation.

Conclusion

Hacking Team’s Remote Control System is a surveillance malware toolkit marketed for “lawful interception” use. We identified and analyzed RCS Android implants that had lures with a political subtext suggesting targets in the Qatif Governorate of Saudi Arabia. Analysis of these implants revealed a range of surveillance functions.

In the past several years, we have researched both Gamma Group and Hacking Team, exposing their global proliferation, and highlighting the technologies and tactics that they use.  Our interest in these groups is not because they create the most sophisticated implants.  Indeed, since the Aurora incident in 2009, there have been many public reports of sophisticated malware used by nation states.  For example, Turla, a campaign attributed to Russia, was described as “one of the most complex cyber espionage programs uncovered to date.” Additional campaigns of note include Careto, linked to Spain [PDF], and Miniduke. Meanwhile, significant analysis and public discussion has gone into the Stuxnet, Duqu, and Flame, which are allegedly a product of US and Israeli collaboration.

These high-impact (and typically high development cost) implant kits all appear to be used exclusively by the countries they are attributed to, and are designed to perform targeted intrusions.

Hacking Team and Gamma Group are different for several reasons.  First, their software is available to all but a few countries, provided they pay.  Second, their software is marketed to target everyday criminality and “security threats,” whereas the state-sponsored campaigns we outlined above are designed to support espionage operations against hardened, high-value targets.

This type of exceptionally invasive toolkit, once a costly boutique capability deployed by intelligence communities and militaries, is now available to all but a handful of governments.  An unstated assumption is that customers that can pay for these tools will use them correctly, and primarily for strictly overseen, legal purposes.  As our research has shown, however, by dramatically lowering the entry cost on invasive and hard-to-trace monitoring, the equipment lowers the cost of targeting political threats for those with access to Hacking Team and Gamma Group toolkits.

Acknowledgements

Seth Hardy, Sarah McKune, Marcia Hoffman, Sebastian Porst, Masashi Crete-Nishihata, Bill Marczak, Ron Deibert, Human Rights Watch, Abeer Allam, and several journalists and researchers who were very generous with their time.

Appendix A: Distributed Hacking Team RCS Architecture

This image shows a distributed Hacking Team RCS collection infrastructure, according to the documents.

Appendix B: List of ‘rilcap’ commands

Commands provided by:

Footnotes

¹ http://developer.android.com/reference/android/Manifest.permission.html
² https://developer.android.com/about/dashboards/index.html