Martin's Blog

14. Lessons for Modern Commercial Spyware

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.

I use the frozen 2014-era source to pose questions and design tests, not to describe any current product. Some lessons follow directly from the source and lab; others are explicitly inferences that a present-day assessment would need to verify independently.

Control-plane lessons from RCS arranged around the people affected by surveillance
BOOK SYNTHESISThe concluding frame: commercial spyware is an organizational control plane, not only an exploit. Security, governance, evidence handling, and reproducibility all have to be assessed around the people exposed to its operation.

Surveillance became an enterprise workflow

The popular image of spyware centers on a clever exploit or a hidden implant. RCS contained both, but the operator platform shows why neither is the whole product. A one-time compromise becomes a service only when an organization can decide who may use it, organize subjects and cases, configure collection, receive material reliably, search it, share interpretations, monitor failures, retain results, and recover after disruption.

The reconstructed hierarchy—groups, operations, targets, factories, agents, and evidence—made surveillance legible to an organization. Typed viewers converted private communications, files, positions, screenshots, calls, and other records into sortable work. Configuration graphs turned platform- specific collection behavior into reusable templates. Dashboards and alerts directed attention toward new activity. System views made collectors, anonymizers, injectors, shards, and backups look like infrastructure to be administered.

That operator experience was a force multiplier. It reduced the amount of specialized knowledge required for each decision after delivery. It separated roles, allowed several people to work on one investigation, and gave managers ways to observe activity and resource limits. It also made repeated intrusion feel bureaucratically normal. The interface used calm administrative nouns— “operation,” “target,” “agent,” and “evidence”—for actions whose human effects could include exposure of relationships, movement, credentials, and intimate communications.

The design test for any modern surveillance product is therefore broader than “what vulnerability does it use?” Investigators should ask:

The last question is crucial. RCS had a detailed audit system for application actions and an elaborate licence system for commercial entitlements. The examined source does not show an equally central, technically enforced record of legal authority for each surveillance act. Customers may have had external procedures; this snapshot cannot answer that question. It shows that the product itself placed commercial and operational control closer to the center of its architecture than rights-based authorization.

Capability and control are different engineering problems

RCS could express fine-grained operator privileges. It created groups and operation membership, stored audit events, encrypted channels, generated certificates, checked licences, monitored components, and separated backend roles. On paper, those are recognizable controls.

The security review found that several did not compose into an effective boundary. Any authenticated operator could replace their own privilege list. A view-only account could reach unsafe task dispatch. Object-ownership checks varied by controller, allowing cross-investigation access and mutation. Active sessions retained a login-time privilege snapshot after an account changed. Machine components shared broad server authority. Some optional deployment paths weakened transport or database trust.

The lesson is not the shallow claim that old software contains bugs. It is that feature-rich control surfaces can create an illusion of governance while one alternate route bypasses them. A privilege matrix is not least privilege if mass assignment can rewrite it. Group membership is not isolation if a generic GridFS endpoint ignores ownership. TLS on the collector-to-database path does not protect the reverse path when the same shared credential crosses plain HTTP. An audit record does not guarantee accountability if a compromised backend can change the database containing the audit.

For a modern assessment, capability assurance and control assurance should be separate workstreams. Capability assurance asks whether the product can deliver, collect, process, and present what it promises. Control assurance asks whether every way to invoke those functions enforces current identity, authorization, scope, purpose, and audit requirements. A system may be highly reliable at the first and dangerously inconsistent at the second.

This distinction also applies to procurement and oversight. A demonstration that a product can narrowly select a target does not show that customer administrators cannot broaden access later. A console screenshot showing an audit page does not show that logs are complete, externalized, tamper-evident, or reviewed. A vendor policy promising suspension does not reveal how misuse is detected, who decides, what evidence is preserved, or whether support and infrastructure access actually stop.

Offensive platforms are high-value targets

RCS was built on the assumption that other machines could be compromised. Its own architecture needed to make the same assumption about operators, collectors, internal networks, archives, and the vendor’s development estate. The source repeatedly falls short of that standard.

The backend concentrated operator credentials, target identities, collected content, agent keys, component secrets, topology, backups, and audit history. Collectors cached cryptographic and factory material so they could continue through a database outage. Archive and connector features produced additional copies of sensitive evidence. The exploit repository accumulated scarce vulnerability knowledge and packaged delivery techniques. Compromising any of those stores could harm not just the product owner but people already exposed to surveillance.

This reverses the conventional direction of the threat model. The monitored person is not the only—or necessarily the most capable—adversary. Other state actors, criminal groups, insiders, rival vendors, hostile customers, and researchers who cross ethical boundaries may all value the platform. An operator backend can be attacked for access to current investigations, an archive for historical content, a collector for topology and protocol material, or a development repository for unreleased exploits.

The 2015 breach made this externality visible. It exposed company and customer records and made private offensive research public. CVE-2015-5119 illustrates the wider consequence: once disclosed, a previously private Flash capability was rapidly available beyond the original vendor-customer relationship. The book does not attribute later campaigns to HackingTeam. The defensible point is that an offensive supplier’s breach can convert a concentrated private risk into a public attack surface.

Security requirements for such a platform should consequently be stricter than for an ordinary case-management application:

  1. components need individual identities and narrowly scoped capabilities;
  2. evidence and control traffic need authenticated encryption across internal as well as external links;
  3. authorization must be centralized, object-aware, current, and deny by default;
  4. audit events must leave the mutable application trust domain;
  5. development, exploit, signing, customer, and evidence environments must be separated;
  6. secrets need inventory, rotation, revocation, and breach recovery; and
  7. independent assessment must include hostile operators and compromised components, not only attacks from the public Internet.

These are ordinary security principles applied to extraordinary data and capability. Calling an internal network “trusted” does not reduce the cost when that trust fails.

Security debt accumulates behind secrecy

Reconstructing RCS required Debian Jessie, Ruby 2.1, era-specific gems, MongoDB 2.6 roles, an OpenSSL-capable EventMachine build, compatibility shims between mismatched repositories, and a replacement for an expired licence. The exercise showed both disciplined engineering and deep fragility. The platform had modular services, schemas, status reporting, tests, and release machinery. It also depended on deprecated interfaces, version-skewed internal libraries, hardcoded assumptions, shared secrets, unsafe Ruby features, and platform-specific shell behavior.

Secrecy can hide this debt from the people who bear its consequences. Customers may see a supported appliance and polished console rather than the parser, session, and authorization shortcuts underneath. Targets cannot choose the product or demand a patch. External defenders may have only samples and network fragments. Independent researchers face legal, ethical, and safety barriers. The ordinary feedback loop that pressures public software to fix security defects is therefore weaker.

That does not mean open source is automatically safe or that classified review cannot be rigorous. It means claims of exceptional secrecy cannot substitute for evidence of engineering assurance. A serious control regime would require secure-development records, architecture and threat models, dependency and secret inventories, reproducible tests, independent source review, documented remediation, and incident disclosure proportionate to the harm. It would also verify that the reviewed build matches what customers operate.

Version provenance is part of that assurance. This archive does not contain one coherent “RCS 9.” The database, common library, console, collector, anonymizer, manuals, and exploit history represent different moments. A claim validated in one cannot silently be applied to another. The same discipline should govern modern vendor assessments: name the exact product, build, deployment mode, enabled feature, and observation date. Marketing family names are not security boundaries.

Evidence systems must preserve doubt

RCS called the material it stored “evidence,” but storage did not establish authenticity, lawful acquisition, accurate attribution, or completeness. Some records could be created or changed by analysts. Some UI summaries depended on cached counts or client state. Connectors could remove the primary copy after export. Backups varied in what they preserved. Audit lived in the same mutable database domain. The security assessment found cross-investigation read and write paths, generic blob access, and direct routes to backend compromise.

Those facts do not show that every historical record was false. They show why the platform itself cannot be the sole witness for its output. A responsible investigation correlates endpoint artifacts, network telemetry, backend records, provider logs, audit history, operator accounts, configuration, external timestamps, and chain of custody. It separates a factory template from a deployed agent, a queued command from an executed one, an analyst- created entity from a collected record, and a target record from proof that a device was compromised.

Modern systems should make those distinctions first-class. Every record needs provenance: collection component, source device, acquisition and receipt time, transformations, analyst edits, exports, retention actions, and cryptographic integrity where appropriate. Derived intelligence should remain linked to its inputs. Corrections should append rather than silently replace. Deletion and export should be auditable. The system should make uncertainty easier to see, not smooth it away for operator convenience.

This is a technical requirement with legal and human consequences. When surveillance output informs detention, prosecution, border action, or threats against a journalist’s sources, an ambiguous provenance field is not merely a database-quality problem.

Exploits became inventory

The exploit catalogue reveals another kind of productization. Internal IDs, manifests, categories, version gates, user-facing parameters, changelogs, and retirement commits converted heterogeneous research into items that a larger system could discover and offer. Antivirus detection, platform change, patch release, and browser evolution affected the shelf life of those items.

That history complicates the idea of an “exploit” as a singular piece of brilliance. Commercial utility also depends on packaging, testing, loader compatibility, documentation, customer entitlement, integration, maintenance, and support. Social delivery paths remained on the final shelf alongside restricted technical entries. The organization did not need an endless set of zero-days if its workflow could combine several routes to access with a stable backend.

For defenders, the useful unit of analysis is therefore the capability lifecycle. When did research enter a development tree? When did a package appear in a customer-facing manifest? Which platform and product versions did it claim? When did antivirus or patching reduce value? Was it removed from one branch while remaining elsewhere? Which metadata claims survive comparison with authoritative advisories?

The appendix preserves 38 normalized catalogue IDs recovered from 46 manifest paths, with only seven present at repository HEAD. That difference is the lesson: a current directory is a snapshot, not an inventory history. At the same time, repository presence establishes none of sale, delivery, successful use, or authorship. Historical reconstruction gains value by preserving those negative boundaries.

Oversight must follow the whole lifecycle

The history in Chapter 1 shows why export licensing matters and why it is not enough. Italian authorities first imposed a licensing obligation, then issued a broad authorization, and later returned the company to transaction-specific review. The official record demonstrates that regulation existed; it also shows how the form of an authorization changes the opportunity to examine particular end users before transfer.

Transfer is only one moment. A surveillance system has a lifecycle:

research -> acquisition -> product integration -> sale -> deployment
   -> target selection -> operation -> support/update -> retention/export
   -> suspension -> decommissioning -> breach/remedy

Oversight that examines only the sale misses target selection, configuration, support, evidence use, onward export, and continued operation after abuse is reported. Oversight that examines only targeting misses vulnerability stockpiles and development security. A suspension policy is incomplete without technical means to identify affected installations, revoke scoped credentials, stop updates and support, preserve records, notify authorities and affected people where safe, and verify decommissioning.

Effective governance also needs independence. Vendor assertions and customer authorizations are evidence, but neither should be the only evidence. Review requires people able to examine source, deployed configuration, audit logs, support history, and human-rights risk without depending on the team whose success is measured by sales or operational results. Remedies must reach the people harmed, not end at a corrected licence entry or a patched console.

The cases discussed in Chapter 1 also caution against measuring control only by whether a vendor states a legitimate-use policy. Credible public reporting of journalist and activist targeting creates a test: what did the control system detect, what investigation occurred, what access changed, and what was communicated? Confidentiality may protect investigations and customers, but total opacity makes effectiveness impossible for victims and the public to evaluate.

What RCS cannot tell us about today’s market

This source freezes an old product in an old ecosystem. Adobe AIR was the operator client. Flash and browser plugins shaped exploit opportunity. Ruby 2.1 and MongoDB 2.6 shaped backend risk. Mobile operating systems, cloud platforms, identity systems, network encryption, exploit markets, and vendor structures have changed substantially since these snapshots.

It would be unsound to infer that a current vendor uses RCS protocols, shares its authorization flaws, stores data in the same schema, or can be detected by the same ports and certificates. It would be equally unsound to infer that newer technology eliminated the organizational problems visible here. Contemporary answers require contemporary evidence.

RCS can instead supply a checklist of hypotheses:

Each is a question to test, not an answer inherited from 2014.

The same restraint applies to detection. Server: nginx, port 443, generic certificate names, MongoDB, and HTTP 444 exist far beyond RCS. Even stronger historical indicators age, collide, or become deliberately copied. Detection must combine signals, declare sensor position and provenance, and be validated against both positive and negative corpora. Historical rules are leads for a defined product version, not timeless labels for commercial spyware.

Why reconstructing old systems still matters

A static archive can reveal dangerous functions. A working but constrained reconstruction reveals relationships: which service must start first, which state survives restart, how a factory becomes an agent record, where evidence enters storage, why a WebSocket heartbeat affects session lifetime, how a UI action reaches a backend controller, and where a version mismatch breaks the chain.

Those observations improve defensive work. They turn vague indicators into combinations with known limitations. They show responders which volatile state to preserve before restarting a server. They distinguish direct fixture data from worker-ingested evidence. They expose security properties that source review can then test systematically. They also prevent a polished manual from being mistaken for the implementation.

The method matters as much as the result. This project froze source versions, kept original leak material read-only, copied only backend components into an isolated lab, documented compatibility patches, replaced the unavailable AIR client with a traceable web port, used synthetic identities and evidence, and made offensive build controls render-only. It recorded failed endpoints, deferred destructive replays, unvalidated hypotheses, and source/manual/lab differences rather than smoothing them into a success story.

That model offers a practical rule for dual-use reconstruction: execute the minimum layer necessary to answer the defensive question. Static metadata was enough for the exploit catalogue. Source and manuals were enough for the collector, anonymizer, and injector chapter. A backend lab was justified for runtime, workflow, evidence, and security questions. Implants and exploits were not necessary, so they remained inert.

Historical work also preserves accountability. Software ages out of support, companies reorganize, infrastructure disappears, and public memory compresses complex events into a few famous vulnerabilities. Reconstructing the mundane parts—the licence check, group callback, queue, export directory, audit row, or decoy response—shows how capability was actually sustained. It creates a record that defenders, courts, policymakers, and affected communities can question without accepting either vendor marketing or sensational summary.

Keep the people, not the product, at the center

The lab can make RCS intellectually absorbing. It is a distributed system with legacy-runtime puzzles, protocol layers, graph editors, sharded collections, and unusual security failures. That fascination carries a risk: the system’s engineering can displace the people whose devices, movements, contacts, and conversations were its raw material.

The correct final unit of analysis is not the exploit, agent, collector, or database. It is the person exposed by the system and the larger circle exposed through them. One address book can implicate sources. One microphone can capture a room. One operator-platform breach can reveal many investigations. One leaked exploit can expand risk beyond every original customer.

Defensive research should therefore minimize sensitive content, use synthetic fixtures, keep raw victim data out of ordinary tickets and demonstrations, describe uncertainty, involve safeguarding expertise, and publish only the detail needed for verification and protection. “The data was in the leak” is not a sufficient reason to repeat it. “The feature existed” is not proof that it was used against a named person. “The system called it evidence” is not a finding of guilt.

The reconstruction began with a question: could an obsolete commercial spyware backend be brought back to life, and could the platform itself be compromised? The answers are yes, within explicit boundaries. More important is what those answers reveal. Surveillance became scalable when intrusion was wrapped in ordinary product engineering. The same ordinary engineering failures—unsafe parsing, inconsistent authorization, shared credentials, weak provenance, brittle dependencies—could expose the operators and the people already under observation.

The enduring lesson is not that offensive systems are secretly ordinary. It is that ordinary choices about identity, scope, logging, storage, product design, and oversight determine how extraordinary power is used, contained, investigated, and remembered.

Sources and evidence

↑ HackingTeam's RCS: Bringing a Commercial Spyware Platform Back to Life