11. The Exploit Business Behind RCS

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.

That attrition turns a directory of offensive software into a record of a business. Exploits were not timeless capabilities. They were inventory with identifiers, categories, supported products, input and output formats, release versions, customer-facing descriptions, compatibility gates, and retirement events. The interesting question is consequently not how to run any one package. It is how a surveillance vendor acquired, packaged, maintained, restricted, and withdrew access methods as the environment around them changed.

I read the repository as an inventory ledger and answer that question from metadata and history only. Nothing in vector-exploit was built, decrypted, repaired, or executed. Package command lines and payload internals are intentionally omitted. The complete normalized inventory is preserved in the exploit catalogue appendix.

An exploit as a product record

The RCS database did not discover exploit capabilities by importing source projects. It scanned an exploits directory for files matching an internal ht-YYYY-NNN convention. A package could be a clear ZIP or an archive encrypted with an embedded product string. The loader opened info.yaml, parsed its metadata, discarded manifests with the wrong version, and exposed the accepted entries to licensed console users (rcs-db/lib/rcs-db/build/exploit.rb:204-283).

The manifest supplied the commercial vocabulary. It named the package, placed it in a category, identified a platform and possible output formats, described its supported software, and declared the parameters the operator interface should request. Other fields told the build system whether delivery involved one file or several and whether another server-side artifact was involved. Those fields form a contract between package, backend, and console. The repository could contain technically interesting source without making it a sellable or selectable operator capability.

This distinction is why the catalogue should not be described simply as “the exploits in the leak.” The snapshot contains at least three different things:

The boundary matters especially for the development tree. It includes Flash, Internet Explorer, Office, and Android projects beyond the seven final catalogue packages. Names and readmes reveal areas of work, but not readiness. A source directory might be a prototype, an input from an outside researcher, a compatibility experiment, a component of a larger chain, or abandoned work. Counting each directory as a customer exploit would manufacture certainty the archive does not provide.

Reconstructing the inventory

The normalized inventory walks all Git history for paths ending in info.yaml, retrieves the newest surviving metadata for each path, records its first and last content-bearing commits, and finds a deletion commit when one exists. Forty-six manifest paths collapse to 38 internal IDs. The difference comes from renames, duplicates, and temporary support paths rather than eight new capabilities.

The scan requires care. Git’s ordinary path history hides one short-lived OS X rename through history simplification, so the inventory uses full history. Two early manifests are not valid modern YAML; a narrow scalar fallback reads only their identity fields without evaluating their contents. One manifest spells HT-2011-007 as HT-2011-0O7, substituting the letter O for a zero. The catalogue groups it under the evident intended ID while keeping the typo visible. These are mundane data-quality problems, but they are also evidence that the repository was a working production tool rather than a curated museum exhibit.

An early ht-2011-019.zip remains a separate edge case. Git history proves the file existed before a cleanup, but no info.yaml can be recovered from the repository objects examined here. It is listed as an opaque package and excluded from every metadata-derived total. Calling it a known exploit would go beyond the evidence.

Capability lifecycle as a state machine

The repository supports a lifecycle model more precise than “present” or “absent”:

research or acquired material
            │
            ▼
development tree ──> packaged archive + manifest
                              │
                              ▼
                    compatible version gate
                              │
                              ▼
                    operator catalogue entry
                              │
                    ┌─────────┴─────────┐
                    ▼                   ▼
             directly selectable   support-restricted
                    │                   │
                    └─────────┬─────────┘
                              ▼
                 maintenance / AV changes
                              │
             ┌────────────────┴────────────────┐
             ▼                                 ▼
       retained at HEAD             removed, patched, failed,
                                    detected, or superseded
                                              │
                                              ▼
                                      Git-history evidence

Each transition needs different evidence. A development directory establishes work, not packaging. A manifest establishes a product contract, not acceptance by this frozen backend. Passing the manifest version gate would establish compatibility with a server line, not customer entitlement. A support stub establishes restriction at the visible interface, not the off-repository approval process. A deletion commit establishes removal from one branch, not eradication from every customer installation.

This model also clarifies the book’s counts:

The state machine is useful beyond this archive. It prevents a source leak from being flattened into an arsenal count and gives defenders better questions: Was the material researched, packaged, accepted by a backend, exposed to an operator, delivered, retired, or merely retained in history? This chapter can answer only the stages for which the repository preserves evidence.

The resulting 38 records divide as follows:

Those are HackingTeam’s classifications, not independently verified vulnerability states. “Private” is a vendor label, not evidence of exclusive possession. “Zeroday” cannot by itself date patch availability. “Public” describes how HackingTeam presented an entry, not whether every part of a delivery chain was public. The labels are still valuable because they show how the company segmented inventory for its own product.

A Windows-shaped catalogue

Thirty-four of the 38 metadata-bearing identities name Windows as their platform. Two name OS X and two name iOS. In other words, 89 percent of the recovered packaged catalogue is Windows-focused. Android appears in the development tree but not as a recovered packaged manifest.

The Windows concentration is broader than Internet Explorer. The older catalogue moves among Microsoft Office documents, Flash and Shockwave content, Safari for Windows, Acrobat Reader, VLC, and disguised archives or documents. The product was following places where a recipient’s ordinary desktop workflow met complex file parsers and browser plugins. Office is particularly persistent: Word entries recur across several years, while the final technical packages combine Word or PowerPoint documents with Flash, alongside an Internet Explorer entry.

The platform table also exposes a trap in historical interpretation. An internal ID beginning with 2010 or 2011 first appears in this Git repository’s surviving history in March 2012. The prefix looks like a year, and probably functions as one in the internal numbering scheme, but the original creation or acquisition date is absent from the examined repository. “First observed” in the appendix means first observed in this history, not first developed or first used anywhere.

The two OS X identities likewise represent different propositions. One was a Safari entry categorized as public. The other was a social package that made an application look like a document. The two iOS records also differ: an older PDF Reader package was categorized private, while the surviving Cydia package assumed a jailbroken device and a user-facing installation path. Lumping all four together as “mobile and Mac exploits” would erase the distinction between software vulnerability, delivery technique, and required device state.

Social delivery was part of the same shelf

Six entries are categorized social. They include fake ZIP and RAR archives, document-disguised executables for Windows and OS X, a self-deleting Windows executable, and the Cydia installer. Four of those six survive at repository HEAD.

That persistence is significant. A patched memory-corruption bug can expire overnight. A technique that depends on presentation, user choice, or an already modified device changes on a different schedule. It may still be detected, blocked by platform policy, or rendered obsolete by interface changes, but it is not tied to a single vendor patch in the same way.

The product model put these social techniques beside entries labelled private and zeroday. From the operator’s perspective they were alternate ways to produce a delivery artifact, not a separate moral or technical category outside the system. This is one of the clearest ways the repository depicts intrusion as a workflow: the catalogue abstracts different prerequisites behind a common selection interface.

The final paths even preserve product-renaming scars. HT-2012-001 appears at HEAD under ht-2014-002-FakeWin, and HT-2014-001 appears under ht-2014-003-ExeSelfDelete. The folder year and sequence no longer agree with the declared identity. The stable key was the manifest ID consumed by the application, while directory names could follow release work. Treating folder names as canonical would double-count packages and invent two identities the console would not see.

Patch Tuesday and antivirus as inventory events

The changelog is unusually candid about why capability disappeared. In July 2012, HT-2012-003 and HT-2012-004 were removed because they no longer worked. In August, HT-2012-005 and HT-2012-008 were removed because antivirus detected them. In February 2013, HT-2012-009 and HT-2013-001 were described as patched and dangerous to use because of antivirus detection. Days later, a broader cleanup removed “all dangerous exploits detected by AV.”

These statements are HackingTeam’s explanations, not independent test results, but their operational logic is plain. Reliability and detection were release criteria. Once a package failed or generated unacceptable risk, the vendor removed it from the product shelf. The commit history is therefore a kind of negative capability log: absence can reflect defensive success even when it does not identify which signature, patch, or behavior caused the retirement.

Antivirus pressure affected social packages too. Later changelog entries say the Windows fake-document package was changed to avoid Avast detection and then changed again to avoid detection. The distinction between “exploit” and “packaging” mattered less to product maintenance than whether the final artifact remained usable against contemporary defenses.

This also explains why a raw count overstates durable capability. The 38 IDs span generations of mutually obsolete software. A package tied to Office 2002 or Safari for Windows cannot be treated as additive to a later Office and Flash path as though all were simultaneously reliable against a modern environment. The catalogue is a timeline, not an arsenal score.

Public stubs, functional variants, and support control

The three final zeroday package trees do not present a single unambiguous manifest. Their public info.yaml files contain support messages and, for the Office entries, empty execution fields. The Word and PowerPoint trees also contain info-good.yaml variants whose metadata points at functional-looking resources. All three checked-out trees also contain info-fake.yaml records, and one path named nobuild-ht-2013-004-Ie actually declares the Word package’s HT-2013-002 identity.

The safest interpretation is narrow. HackingTeam maintained different manifest faces for at least some restricted packages, and the checked-out public face directed operators to support. This resembles a control point: possessing a repository tree did not necessarily mean an installation would receive a directly usable catalogue record. It may have allowed the vendor to mediate enablement, delivery, customer eligibility, or package replacement.

The archive does not establish the exact selection mechanism or contractual rules. No reviewed code proves which customers received info-good.yaml, who performed the substitution, or whether the checked-out state was meant for a release. “Support-gated” is a useful description of the visible interface; claims about per-customer exploit entitlement remain inference.

The backend imposed another, more mechanical gate. The examined RCS 9.2.3 loader accepts only manifest version 20140512, while the seven repository HEAD manifests declare 20140930. The repository VERSION is 2014093001. A literal pairing of these two frozen snapshots would discard the later catalogue entries at reload time (rcs-db/lib/rcs-db/build/exploit.rb:228-254).

The loader opens each recovered package, reads its YAML manifest, and applies the literal version gate before adding it to the catalogue:

# rcs-db/lib/rcs-db/build/exploit.rb:242-254
Zip::File.open(clear_file) do |z|
  info = z.file.open('info.yaml', 'rb') {|f| f.read}
  info = YAML.load(info)
end

FileUtils.rm_rf clear_file

next unless info['version'] == 20140512
info[:package] = exp
list << info

This is package-management code, not exploit code. It demonstrates why catalogue presence and compatibility are separate propositions.

This is not evidence that HackingTeam shipped a broken product. It is evidence that the leak contains components from different release lines. A later database build presumably matched the later catalogue, but that exact pairing has not been established here. Version gates were part of release control, and they are also one more reason not to treat every leaked directory as a capability available to the reconstructed backend.

A release train rather than a vault

Read chronologically, the repository behaves less like a vault of finished techniques and more like a release train. The earliest surviving conversion commits in March 2012 introduce or unpack a large back catalogue at once. Several records carrying 2010 and 2011 IDs appear for only a day before a cleanup removes them. Others survive into the broad February 2013 purge. That shape implies migration from an earlier packaging system or repository, but the predecessor has not been recovered here. The first Git appearance is a lower bound on age, not an origin story.

The middle of 2012 shows faster product churn. Two Word packages arrive in March and are removed in July as no longer working. New Word variants arrive in April, May, and June; two are removed in August over antivirus detection. A Cydia installer appears in June and survives to HEAD. Another Office and Flash package appears in September, is revised in November, and is removed the following February after patching and detection. The dates describe repeated integration and withdrawal, not a one-time dump of research into a product.

The 2013 sequence is more concentrated. The cleanup cuts away most of the old catalogue in February. A new Word package appears in April, PowerPoint in May, and Internet Explorer in July. Those three become the final technical entries. Later commits mostly maintain the delivery shelf: OS X and Cydia fixes, new self-delete and fake-document releases, and changes described as avoiding antivirus detection. The December 2014 repository tip changes handling of names containing spaces but leaves the catalogue version at September 2014.

Version numbers support this picture. Historical manifests commonly declare 20120101 or 20120701; the iOS PDF record reaches 20130311; final records declare 20140930. These are compatibility markers rather than semantic versions. The backend compares them for exact equality instead of negotiating a range. Updating a package catalogue was therefore coupled to updating the server line that understood it. An operator could not simply drop every historical package into every database release and expect a combined shelf.

This coupling has an organizational consequence. Someone had to coordinate research output, manifest shape, backend acceptance, console presentation, licensing, and customer support. Exploit development might be highly specialized, but productization required ordinary release engineering. The repository’s errors do not negate that process; they show where its manual edges remained.

CVE labels require external validation

The manifests use a mixture of CVEs, Microsoft bulletins and KB numbers, Adobe bulletin identifiers, product versions, and informal vulnerability descriptions. These identifiers are not interchangeable. A cumulative bulletin can contain several CVEs; a product version can be exposed to many bugs; and a vendor’s internal label can simply be wrong.

The catalogue preserves broad labels without guessing a one-to-one mapping. For example, Microsoft says MS11-081 was a cumulative Internet Explorer update covering multiple vulnerabilities. A manifest that says “before KB2586448” does not identify which one it used. By contrast, MS11-031 describes one scripting-engine vulnerability, CVE-2011-0663, so that mapping can be made without selecting among several candidates. Microsoft’s bulletin describes remote code execution through a crafted web page and lists the single CVE under its vulnerability table (Microsoft MS11-031).

HT-2011-007 is also a defensible mapping. Its manifest explicitly names CVE-2011-0609 and Adobe Flash bytecode verification. The NVD record covers Flash Player and crafted Flash content, including an in-the-wild Office delivery example (NVD CVE-2011-0609). This validates the vulnerability identity; it does not validate every version or delivery claim in HackingTeam’s description.

HT-2010-059 demonstrates why the check matters. Its manifest labels an iOS PDF Reader package CVE-2010-1095. The authoritative record for that ID instead describes cross-site scripting in an unrelated requirements-tracking application (NVD CVE-2010-1095). The mismatch is not subtle. The appendix therefore records “manifest claim contradicted” and leaves the iOS vulnerability unmapped. Substituting a more plausible iOS CVE without direct evidence would merely replace one unsupported claim with another.

CVE-2015-5119: when private inventory became public risk

The most consequential exploit in the leak was not one of the seven final catalogue manifests. It lived in the Flash development material and became a public vulnerability record after disclosure: CVE-2015-5119, an ActionScript ByteArray use-after-free affecting Flash Player across Windows, OS X, and Linux. Adobe released fixed Flash versions on 8 July 2015, as recorded in contemporary reporting (Mandiant); the NVD record identifies affected releases, associates the fix with APSB15-16, and notes exploitation in July 2015 (NVD CVE-2015-5119).

The breach had a claimant and a technical narrative

The archive did not simply appear without an attributed actor. The pseudonymous hacktivist usually known as Phineas Fisher—with Phineas Phisher also used as a rendering of the name—claimed responsibility while HackingTeam’s own accounts were still under the intruder’s control. Contemporary reporting linked that claim to the persona that had claimed the 2014 breach of Gamma International, maker of FinFisher (Vice, July 2015).

In April 2016 the persona published a Hack Back! guide describing the operation in first person. The account says an undisclosed vulnerability in an Internet-facing embedded device provided the initial foothold, followed by internal reconnaissance, access to weakly protected MongoDB and storage, credential acquisition, and exfiltration of mail, files, and source code. It explicitly presents the HackingTeam operation as a successor to the earlier Gamma/FinFisher breach (English translation; contemporary discussion).

The guide matters because it supplies a coherent attacker-side narrative for how an offensive-security vendor lost its own research estate. It is not, however, a neutral incident report. The author withheld the initial vulnerability, wrote under an unidentified persona, and mixed technical detail with political argument. The defensible attribution is therefore that Phineas Fisher claimed and contemporaneously demonstrated control consistent with the breach, then published a detailed account—not that the underlying person or every technical assertion has been independently proven.

The same runtime family sat on the operator’s desk

There is an operator-side irony, but it needs a precise description. Adobe AIR did not require the browser Flash plug-in. It was a separate desktop runtime that used the same ActionScript language and virtual-machine family. The recovered RCS Console identifies itself as an AIR 15.0 application, with a build label dated 21 March 2015 (rcs-console/src/Console-app.xml:2,29-32). The descriptor does not set a minimumPatchLevel. Its 15.0 namespace establishes the runtime features the application requires; it does not prove that every operator remained on AIR 15, because newer AIR runtimes can read older application descriptors (Adobe AIR application-descriptor documentation).

The distinction did not make AIR irrelevant to the leaked zero-day. Adobe’s APSB15-16 bulletin included AIR Desktop Runtime 18.0.0.144 and earlier among the affected products, listed CVE-2015-5119 among the resolved vulnerabilities, and directed desktop users to AIR 18.0.0.180 (Adobe APSB15-16). An operator workstation still using the AIR 15 generation was therefore in the affected range. The same vulnerability family being developed for victim delivery also existed beneath HackingTeam’s own operator interface.

That fact establishes exposure, not a demonstrated route to compromise. The Console did not automatically execute the exploit packages offered through RCS. Its source does, however, render evidence-derived HTML and pass downloaded image bytes into AIR display components (rcs-console/src/it/ht/rcs/console/utils/SearchableHTML.mxml:244-249; rcs-console/src/it/ht/rcs/console/operations/view/evidences/renderers/Screenshot.mxml:70-96,122-135). Those parsing surfaces made the operator workstation a plausible reverse-targeting surface in the broader sense. The examined code does not show that crafted victim content could reach the particular CVE-2015-5119 trigger, and no evidence reviewed here shows that an operator was compromised through the Console. The defensible conclusion is narrower: unpatched operators depended on a runtime family affected by vulnerabilities their supplier was simultaneously turning into offensive inventory.

The sequence illustrates a risk larger than HackingTeam’s own operations. Once the archive was public, a capability held inside a commercial spyware vendor became available to unrelated actors. Unit 42 found shared classes, function names, and logic between HackingTeam’s Flash material and an attack targeting the US government (Unit 42). Mandiant reported that two separately tracked groups used CVE-2015-5119 in phishing campaigns immediately around the patch window (Mandiant).

These reports do not show that those actors had been HackingTeam customers or that HackingTeam directed their activity. They support a different conclusion: disclosure collapsed the scarcity that gave the private capability commercial value. Source exposure shortened the path from vendor inventory to broad reuse, while defenders and Adobe raced to identify, detect, and patch it.

That externality changes how an offensive vendor’s own security should be evaluated. A breach can expose customer records and victim data, but it can also release unpatched techniques to actors with no relationship to the vendor. Chapter 10 showed direct compromise paths inside the RCS backend. The CVE-2015-5119 episode shows the potential downstream cost when an offensive supplier fails to protect its research estate.

What the catalogue says about the organization

The repository depicts exploit work as a supply chain. Internal numbering turns heterogeneous techniques into stock-keeping units. Manifests translate technical prerequisites into UI fields. Categories communicate commercial status. Version checks align packages with releases. Alternate manifests and support text limit direct availability. Changelog and deletion commits retire unreliable or detectable stock.

It also depicts continuous acquisition rather than one stable internal arsenal. New Office and browser entries arrive over time; older packages are removed; development directories carry individual researcher names and specialized stages; published records later identify at least one leaked Flash capability with a distinct researcher. The evidence supports an organization integrating work from multiple projects and people. It does not, by itself, prove the contractual origin of every package or whether each was developed in-house, purchased, commissioned, or adapted.

The final seven-entry shelf is therefore not evidence that exploit work had become unimportant. It is evidence that packaged capability was selective and perishable. Three restricted technical entries coexisted with four social paths, while additional research remained outside the customer catalogue. The company did not need every historical package to keep its surveillance platform useful. It needed a maintained path from access opportunity to a configured agent and then into the evidence workflow described in Chapter 7.

Reading offensive catalogues defensively

For defenders, repository history supplies several lessons.

First, use manifests as leads, not truth. Product labels should be tested against vendor advisories and authoritative vulnerability records. Preserve errors because they can reveal provenance, but do not promote them into detection logic or historical fact.

Second, distinguish capability state. Packaged-at-HEAD, recoverable only from history, and development-only are three different confidence levels. A file’s presence says nothing by itself about sale or deployment. A deletion reason can establish vendor intent without proving that every copy disappeared from customer systems.

Third, model lifecycle signals. Patch release, antivirus detection, browser retirement, plugin removal, document-format changes, and platform policy can each end or reshape utility. The February 2013 cleanup shows that detection can be important enough to remove whole groups of packages from a product.

Finally, secure the research supply chain as though it were production. A private exploit repository is a concentrated hazard. Access controls, segmentation, individual identities, peer-reviewed release processes, tamper-evident audit, and prompt vendor coordination are not administrative overhead. They are controls against converting one organization’s stockpile into everybody’s attack surface.

The catalogue is valuable precisely because we do not need to run it. Its metadata, version gates, inconsistencies, additions, and deletions already show a commercial spyware company turning vulnerability research and social delivery into maintained product inventory. Its history also shows the limit of that control. Patches and antivirus retire capabilities from one shelf; a breach can place a still-unpatched capability onto thousands of others.

What the history cannot answer

The inventory is detailed enough to invite questions it cannot settle. It does not reveal which packages were enabled for which customers. A manifest at HEAD shows repository state, not a sales entitlement. The licence check in the backend controls access to the exploit feature as a whole, while the support stubs hint at finer operational control outside the examined code. Invoices, support exchanges, or a matching production package set would be needed to connect an identity to a customer.

It also does not measure success. A claim that a package “passes AV scanning” or supports a particular product version is vendor metadata. No historical test matrix, sample set, product build, or antivirus corpus was reproduced. Deletion after detection is good evidence that HackingTeam cared about that condition; it is not a measurement of how long the package remained undetected in the field.

Nor does the history establish acquisition. Researcher names and separate development projects can identify contributors or origins worth investigating, but repository possession alone cannot distinguish employment, contracting, purchase, licensing, partnership, or later import. The book consequently uses “HackingTeam catalogue” to mean inventory held and packaged by the company, not necessarily vulnerabilities first discovered by its employees.

Finally, the inventory says almost nothing about use against an individual. Exploit metadata contains supported platforms, not victim attribution. Connecting a package to an operation would require contemporaneous deployment records, target-side artifacts, network telemetry, or trustworthy reporting. The ethical boundary is the same as the technical one: preserve enough detail to understand the product and help defenders, but do not turn unsupported association into a claim about a person or organization.

These limits make the negative findings important. No manifest means no metadata claim. A development directory means research, not delivery. A retired entry means removal from this repository line, not eradication from every installation. A valid CVE mapping identifies a vulnerability, not an operation. Keeping those statements separate is what turns leaked material into a defensible historical record instead of a list of suggestive names.

Sources and evidence

• SOURCE: vector-exploit at commit 2cf574d3bf2ea44f67433e32ccc9906ded6218e0, including VERSION, CHANGELOG, manifest history, and development-tree names and readmes.
• SOURCE: reproducible static normalization in research/hackingteam-rcs/exploit-catalogue/inventory.rb; 46 manifest paths, 38 normalized IDs, seven IDs at HEAD.
• SOURCE: rcs-db/lib/rcs-db/build/exploit.rb:204-283 for package discovery, metadata loading, licensing, and the 20140512 version gate.
• SOURCE: rcs-console/src/Console-app.xml:2,29-32 for the AIR 15.0 application namespace and March 2015 build label; Console HTML and image renderers cited above for operator-side parsing surfaces.
• CLAIMANT ACCOUNT / REPORTING: the translated Phineas Fisher Hack Back! narrative and the linked contemporary Vice reporting for the HackingTeam and Gamma/FinFisher responsibility claims. The narrative is treated as a first-person claim, not an independently authenticated forensic report.
• REPORTING: Adobe APSB15-16, the NVD records for CVE-2015-5119, CVE-2011-0609, and CVE-2010-1095, Microsoft MS11-031 and MS11-081, and the linked Unit 42 and Mandiant investigations.
• LIMITATION: internal categories and removal explanations are the vendor’s claims. Presence does not establish sale, deployment, successful use, or exclusivity. No exploit package was built, decrypted, or executed.