HackingTeam's RCS: Bringing a Commercial Spyware Platform Back to Life on Martin's Blog

HackingTeam, RCS, and Its Human Consequences

Mon, 01 Jan 0001 00:00:00 +0000

Before this book brings an old surveillance application back to life, it needs to say what that application was for.

HackingTeam was founded in Milan in 2003 and sold intrusion and surveillance software to government and law-enforcement customers. Its flagship platform, the Remote Control System, appeared under the names Da Vinci and later Galileo. The product joined covert collection on computers and phones to the ordinary machinery of an enterprise investigation: user accounts, work groups, targets, evidence databases, dashboards, alerts, audit records, backups, and a desktop analyst console.

Anatomy of a Surveillance Platform

Mon, 01 Jan 0001 00:00:00 +0000

RCS is easiest to misunderstand when reduced to “spyware.” The implant was one part of the product, but the product was an investigation system. It connected covert collection to users, permissions, target records, evidence processing, search, alerting, topology management, and backups. The leaked manuals describe both an all-in-one installation and a distributed deployment, and the source tree supplies the services behind those diagrams.

I use platform deliberately. The implant collected. The surrounding system made that collection repeatable, searchable, shareable, and administratively ordinary.

Archaeology of an Inconsistent Leak

Mon, 01 Jan 0001 00:00:00 +0000

There is no single version of RCS in the archive examined for this book. There are several repositories that happened to be present when the material was copied, and their branch tips do not describe one product release. Once I compared the embedded repository histories, the archive stopped looking like a release and started looking like a developer’s workspace. Treating the directory tree as a coherent source distribution would make the reconstruction look simpler than it was—and the resulting claims less reliable.

Time-travelling the Runtime

Mon, 01 Jan 0001 00:00:00 +0000

Making old source code compile is not the same as reconstructing the system it belonged to. RCS depended on a particular Ruby generation, native extensions, old library behavior, a sharded MongoDB deployment, generated certificates, licence state, and interfaces shared across several repositories. Replacing each obsolete part with a current equivalent would have produced a different application—if it produced a working application at all.

I treated the job as conserving a machine, not porting a program. The lab recreates the narrow historical environment the backend expects, applies only the compatibility changes needed to bridge the surviving source snapshots, and puts modern isolation around the result. The application inside the container remains old. The safety boundary around it is new.

Licensing, Identity, and Trust

Mon, 01 Jan 0001 00:00:00 +0000

When I traced RCS’s trust checks through the source, the broad label split into several narrower mechanisms. The system verified that a licence had the right shape and cryptographic checks. It could bind that licence to a hardware token. It generated a private certificate authority for encrypted service connections. It hashed operator passwords and issued session cookies. It also gave backend components a shared credential that admitted them as servers.

Rebuilding the Operator Console

Mon, 01 Jan 0001 00:00:00 +0000

Once the backend ran, I could query it through REST and MongoDB. I still could not see RCS as an operator saw it. The product was designed around a large Adobe AIR application whose console decided which sections a user could see, loaded and patched shared collections, translated a nested operation graph into screens, rendered about twenty evidence types, built configuration graphs, and turned asynchronous backend pushes into visible state.

From Synchronization to Stored Evidence

Mon, 01 Jan 0001 00:00:00 +0000

An RCS operator did not receive a folder of raw implant output. By the time a record appeared in the Evidence grid, several systems had already decided which agent it belonged to, decrypted and decoded it, extracted searchable terms, separated binary content, updated counters, evaluated alerts, and placed optional work into other queues.

That transformation is the center of the product. The implant might have collected a keystroke, photograph, file, location, or message, but the backend turned it into something an analyst could filter, tag, annotate, export, delete, and connect to an investigation. It also created a second problem: RCS had to preserve the confidentiality and integrity of an unusually sensitive database while letting many asynchronous components modify it.

Inside an RCS Investigation

Mon, 01 Jan 0001 00:00:00 +0000

RCS makes the most sense when followed as a piece of work rather than a list of components. An administrator creates users and groups. An analyst opens an operation and its targets. A technician prepares a factory configuration. A synchronizing instance becomes an agent record. Evidence appears in typed views, acquires notes and relevance, feeds entities and dashboards, and can trigger personal alerts. Other sections expose the health and infrastructure that keep that workflow moving.

Collectors, Anonymizers, and Injection Infrastructure

Mon, 01 Jan 0001 00:00:00 +0000

The backend reconstructed in the preceding chapters was only the protected half of RCS. A working surveillance service also needed an edge: machines that could receive traffic, conceal the database tier, move material between trust zones, and, in some deployments, interfere with a target’s web traffic. The product divided those jobs among collectors, anonymizers, a network controller, Network Injectors, and connectors.

I drew the execution boundary at that edge. The lab runs the database, worker, and defensive web console. It does not run a collector, anonymizer, Network Injector, implant, or exploit, and it does not connect to any historical or current infrastructure. Synthetic collector, injector, and connector records make the System views inspectable; they do not show that the corresponding services operated. Unless a paragraph explicitly says otherwise, behavior in this chapter comes from static source or the RCS 9 manuals, not packets observed in the lab.

Could RCS Itself Be Compromised?

Mon, 01 Jan 0001 00:00:00 +0000

Yes.

In the examined RCS database source, a user with the least operator role can reach code execution in the backend process. Any authenticated operator can also grant themselves every application privilege. Beyond those direct compromise paths, inconsistent ownership checks expose evidence and agent controls across investigations, while shared component credentials and weak service-to-service trust turn one compromised component into a possible route through the rest of the platform.

That answer needs boundaries. It is a source-backed assessment of the frozen RCS database snapshot reconstructed for this book, not evidence that somebody exploited a historical customer. The review was intentionally defensive and static-first: no implant or exploit code was built or run, no weaponized payload was used, and no external RCS infrastructure was contacted. The current lab also suppresses several original deployment paths by keeping MongoDB and the worker internal and relying on an isolated host. The console and published backend ports are loopback-only, but still require host-level isolation. These controls reduce reachability; they do not repair the underlying code.

The Exploit Business Behind RCS

Mon, 01 Jan 0001 00:00:00 +0000

The most revealing number in HackingTeam’s exploit repository is not a CVE. It is seven.

Only seven catalogue identities remained in the final source snapshot: four social-delivery packages and three entries labelled zeroday. The Git history contains 38 identities with recoverable metadata, plus one early encrypted package whose manifest is no longer recoverable. Thirty-one metadata-bearing entries had therefore disappeared from the final operator catalogue. Some had stopped working. Some had been patched. Some were detected by antivirus products. Others vanished in broad cleanup commits whose own descriptions call them dangerous to use.

Detecting RCS

Mon, 01 Jan 0001 00:00:00 +0000

The easiest way to write a bad RCS detection is to start with Server: nginx. The examined backend places that value on every REST response, and its error pages imitate nginx. It is a real product behavior. It is also shared by an enormous population of ordinary web servers.

Ports 80 and 443, Ruby, MongoDB, a ten-year certificate, ACME Corp, and a directory named backup have the same problem. Each belongs in the investigation. None independently identifies HackingTeam.

Investigating a Suspected RCS Deployment

Mon, 01 Jan 0001 00:00:00 +0000

The first impulse on finding an RCS login page is often to try the default administrator password. That is precisely the wrong first action.

Logging in is not passive. RCS creates and invalidates session state, writes audit records, updates recent activity, and may send a “used on another machine” logout push to an operator already connected as the same user. A browser session can reveal that investigators are present. Restoring a backup, opening a task workflow, deleting a suspicious record, or compacting MongoDB changes far more.

Lessons for Modern Commercial Spyware

Mon, 01 Jan 0001 00:00:00 +0000

RCS looked most powerful when nothing exceptional was happening.

An administrator created accounts. A technician selected options in a form. An analyst opened an operation, filtered a table, added a note, pinned an item to a dashboard, and configured an alert. A worker transformed incoming bytes into records. A connector copied selected records elsewhere. Backup jobs, licence checks, status monitors, and audit views surrounded the process.

The extraordinary act—covertly compromising another person’s device—had been absorbed into ordinary enterprise software. That is the central lesson of this reconstruction. Commercial spyware scales not only through a vulnerability or an implant, but through everything that turns intrusion into routine work: packaging, permissions, queues, templates, evidence schemas, support, monitoring, export, and an interface that lets an operator move through it all without confronting the person on the other side.

Appendix A: Complete Exploit Catalogue

Mon, 01 Jan 0001 00:00:00 +0000

This inventory is compiled statically from the vector-exploit packages' info.yaml metadata, the repository’s Git history, and its development tree. Nothing in the repository was built, run, repaired, or improved.

The packages use internal tracking numbers (HT-YYYY-NNN). The loader accepts clear ZIP archives or archives encrypted with a source-embedded passphrase from the server’s exploits/ directory. The passphrase is not reproduced. When the catalogue is requested, the server’s exploit loader scans that directory and publishes each compatible package’s declared metadata to the console, using the categories social, zeroday, private, and public.

Appendix B: Reproducing the Defensive Backend Lab

Mon, 01 Jan 0001 00:00:00 +0000

This appendix reproduces the constrained research environment used for the book. It starts the original RCS database and worker code in containers, provides the MongoDB topology they expect, and serves the newly written web console on loopback. It does not reproduce an operational surveillance deployment.

The procedure never builds or runs an implant, exploit, collector, anonymizer, Network Injector, delivery package, or original AIR console. Those repositories remain static evidence. The web console renders historical build and installer controls but is designed and tested not to submit build tasks.

Appendix C: Original-to-Lab Patch Inventory

Mon, 01 Jan 0001 00:00:00 +0000

This appendix accounts for the differences between the read-only leaked source and the copies used by the defensive lab. It exists to prevent a lab observation from being silently attributed to original HackingTeam code.

The comparison was refreshed after the reproduction guide. Excluding generated runtime directories and Git metadata, the copied backend contains five modified original files, one lab-only source file, and 601 intentionally omitted original files. The copied common library contains all 115 original files, of which five are modified. In total, exactly ten carried source files differ from their reference copies.

Appendices D–E: Source, Version, and Fidelity Map

Mon, 01 Jan 0001 00:00:00 +0000

This appendix identifies the source snapshots and execution boundaries behind the book. It is a working research artifact and will grow as the claim ledger is reviewed.

Source snapshots

Component	Examined commit	Commit date	Declared or inferred line
`rcs-db`	`6cff59d28634d718cac9fdd17cb629fd59a3cf3f`	2014-05-12	9.2.3; build `2014051201`
`rcs-common`	`38290d4eab2b2c295bea021429848a3666647827`	2015-03-31	9.6.0
`rcs-collector`	`42cf61af9ec3e7b886e87eac20e762c3ce51c78c`	2015-03-31	9.6 branch tip
`rcs-console`	`a90041fcd32bf1a82276ac20c2cd5ecb7d108db0`	2015-03-31	sends RCS version 9.6.0
`rcs-console-library`	`97531201600a8a223392e955a35b2b2605c1c1d4`	2015-03-31	9.6 branch tip; REST/service layer
`vector-exploit`	`2cf574d3bf2ea44f67433e32ccc9906ded6218e0`	2014-12-12	catalogue build `2014093001`
`rcs-anonymizer`	`0c4189b1e5d7e23ad0bf85d0f184d9d8e46decbe`	2015-04-03	supporting static tree; commit identifies 9.6.0

The first six rows are the primary snapshots frozen before drafting; the anonymizer is the supporting static tree cited by Chapter 9. The Git commit date describes the examined repository tip. It is not a product release date and offers no evidence that the components were deployed together. The connector implementation cited in Chapters 9 and 10 resides inside the rcs-db tree at lib/rcs-connector/ rather than in a separate repository.

Appendix F: IOC Catalogue

Mon, 01 Jan 0001 00:00:00 +0000

This catalogue turns the reconstruction into defensive leads. It covers the RCS operator/backend platform and the deployment edge visible in the examined source. It is not a universal signature for HackingTeam products, and it does not claim to identify every implant, customer configuration, successor product, or later version.

An indicator’s value depends on where it is observed. A TLS issuer can be seen on a network sensor. A REST path normally requires TLS termination. A service name requires host telemetry or a forensic image. A MongoDB collection shape requires database access. The tables preserve that sensor position together with provenance and false-positive limits.

Appendix G: Detection-Rule Listings

Mon, 01 Jan 0001 00:00:00 +0000

This appendix records the experimental detection rules developed from the backend and operator-side reconstruction. It is a publication snapshot, not a claim that the rules are production-ready and not a complete detector for HackingTeam products. The authoritative working files remain under research/hackingteam-rcs/detections/; the copies below let a reader review the exact logic without having to infer it from prose in Chapter 12.

The rules cover the RCS database, service installation, collector-facing traffic, licence files, launchers, and certificate-generation source. They do not attempt to identify implants or exploit packages. No implant, exploit, collector, anonymizer, or injector was executed to create this rule set.

Appendix H: API and Storage Map

Mon, 01 Jan 0001 00:00:00 +0000

This appendix maps the examined RCS database API to its MongoDB storage. It is designed for source review, defensive reconstruction, and incident response—not as an operator tutorial. Request bodies, credential values, implant configuration, build parameters, and exploit-delivery instructions are deliberately omitted. The map describes the frozen original rcs-db source; lab-only proxying and safety controls are identified separately.

The central caution is that neither the URL structure nor the collection layout is an authorization boundary. The dispatcher authenticates a session, then individual controller actions apply symbolic privileges. Some actions also filter documents by denormalized user membership, while others do not. Chapter 10 assesses those inconsistencies. A responder should use this map to find evidence on an authorized forensic clone, not to infer that a reachable route is safe to call.

Appendix I: Source Commits, Manuals, and References

Mon, 01 Jan 0001 00:00:00 +0000

This appendix is the book’s consolidated provenance index. It identifies the immutable source revisions, manual files, research artifacts, and external works used across the chapters. It does not replace the local citation beside a claim: a commit identifies a tree, while a file and line range identify the evidence inside it.

Paths beginning with data/ refer to read-only leak material in the defensive research workspace. Paths beginning with docker-lab/ refer to the isolated reconstruction or its documentation. Paths under research/hackingteam-rcs/ are book research artifacts. No repository or manual hash establishes that the material was deployed by a particular customer.

Appendix J: Glossary

Mon, 01 Jan 0001 00:00:00 +0000

This glossary defines terms as they are used in this book. Some are HackingTeam product terms, some come from the underlying technologies, and some are research distinctions introduced to prevent the evidence from saying more than it can support.

The product uses target as a database-object name. When discussing people, the book prefers “person targeted,” “affected person,” “victim,” or the more precise description supported by the evidence. A record labelled evidence by RCS is called RCS evidence or an evidence record; the label does not make its contents independently authentic.