Citizen Lab: Intelligence Source Guide
The Citizen Lab at the University of Toronto publishes forensic investigations into mercenary spyware, censorship and app surveillance, usually with indicators attached. It is the field’s public-interest threat intelligence team for civil society targets, and it is deliberately slow.
The Citizen Lab at the University of Toronto publishes forensic investigations into mercenary spyware, censorship and app surveillance, usually with indicators attached. It is the field’s public-interest threat intelligence team for civil society targets, and it is deliberately slow.
At a glance
| Source | Citizen Lab |
|---|---|
| Category | Conflict, Crime & Human Security › Transnational Repression & Digital Rights |
| Homepage | https://citizenlab.ca/ |
| Format | HTML |
| Access | Open — no account required |
| Disciplines | Cyber Intelligence, Social Media Intelligence |
| Mission domains | Transnational Repression |
Targeted surveillance/spyware investigations. — as catalogued in the platform’s own source registry.
The Citizen Lab is an interdisciplinary research laboratory at the Munk School of Global Affairs and Public Policy, University of Toronto, founded in 2001. It publishes long-form technical reports rather than operating a feed. Three research lines dominate. The first is targeted digital threats against civil society: forensic examination of devices belonging to journalists, human rights defenders, lawyers and opposition figures who consented to analysis, combined with internet scanning that maps the command-and-control infrastructure of commercial spyware products, and the resulting attribution of deployments to government customers. The second is network interference: measurement of censorship and traffic manipulation, including analysis of filtering appliances deployed at national scale and the keyword censorship implemented inside widely used messaging platforms. The third is application security and privacy analysis of software used by hundreds of millions of people, particularly software developed under jurisdictions with data access mandates. Outputs are HTML reports with technical appendices, occasionally accompanied by indicator lists in public repositories, and the lab also maintains the URL categorisation test lists used by independent censorship measurement projects. There is no API, no STIX feed, and no subscription.
Commercial threat intelligence covers what its customers pay for, which is enterprise and government infrastructure. Mercenary spyware deployed against a small number of exiles, lawyers and reporters is commercially uninteresting, technically expensive to find, and politically awkward to publish. Citizen Lab exists in that gap. The analytical product it uniquely supplies is attributed, forensically grounded evidence linking a specific surveillance product to a specific government customer targeting a specific category of person — a chain that vendors design their business model to prevent anyone from establishing. That chain is what makes export control designations, litigation, platform enforcement actions and sanctions arguments possible; several of the most consequential regulatory actions against the spyware industry rest on this lab's findings. For a threat intelligence practitioner the second value is technical: the reports document exploitation chains, persistence mechanisms and infrastructure patterns for products that never appear in commodity malware reporting, and they frequently identify the vulnerabilities that subsequently become tracked CVEs. For a country or human rights analyst, the value is the customer map: knowing which states operate which capability, and against whom, is a governance fact as much as a technical one.
Who publishes it, and why that matters
This is an academic laboratory inside a public university, funded by philanthropic foundations and research grants, directed for its whole existence by a small senior team. The consequences for you are structural. Output is irregular and event-driven — there is no publication schedule, and quiet periods reflect research cycles rather than an absence of activity. Investigations are slow because they are held to an evidentiary standard that will survive legal challenge and vendor denial, which is why the reports hold up years later and why they arrive months after the events they describe. Access to victims is consent-based and relationship-based, which shapes what gets investigated: the lab sees the cases that reach it through civil society networks, not a representative sample. Being a university lab also means it operates under academic freedom protections and institutional research ethics review, both of which are load-bearing — the ethics process is why victim identities are handled the way they are. It also means adversaries have targeted the lab itself, including documented attempts by private intelligence operatives to infiltrate its researchers under false pretences. Treat published findings as unusually reliable and publication timing as unusually unpredictable.
Provenance is the first question to ask of any dataset and the one most often skipped. Who collects it, what their incentive is, whether they publish a methodology, and whether they correct the record when they get something wrong all bear directly on how much weight a finding drawn from it can carry.
What a record actually contains
The fields you will be working with, what each one means, and whether it is something you can pivot on. Read the meanings carefully — more analysis is wrecked by misreading a field than by failing to find one, and a field that looks like an observation is often an inference.
| Field | Type | What it means | Pivot value |
|---|---|---|---|
report_title |
string | The publication itself, which is the atomic unit of this source. Findings live in prose and appendices, not in records, and the report title is the citable identity. | Citation graph, subsequent vendor responses, regulatory actions referencing the report. |
publication_date |
timestamp | When the report was released, which typically lags the targeting activity by months and the vendor's infrastructure by longer. It is not the date of compromise and not the date of discovery. | Timeline construction — but always against the incident dates stated in the body, not the publication date. |
spyware_family |
string | The commercial product or malware family, named either by the vendor's own product name or by a name assigned by the lab or a partner. Naming across vendors and researchers is inconsistent. | Vendor corporate research, export licensing records, sanctions and entity listings, other vendors' detection names. |
vendor |
string | The company that develops and sells the capability, where identified. Vendor identification is a separate and harder finding than family identification and is frequently the litigated part. | Corporate registry records, beneficial ownership, investor structure, export control designations. |
operator_cluster |
string | An inferred customer — typically a government agency — identified by clustering infrastructure and targeting patterns, often labelled with a country attribution and a confidence statement. | Country dashboards, agency identification, procurement and budget research. |
target_category |
enum | The class of person targeted: journalist, lawyer, human rights defender, opposition politician, exile, family member. Individual identities are published only with informed consent. | Transnational repression case databases, press freedom monitoring, exile community risk assessment. |
indicators |
array | Domains, IP addresses, certificate attributes, process names, file paths and forensic artefacts published in appendices. Not always present, and deliberately partial where publication would burn a detection method. | Passive DNS, certificate transparency, hosting and registrar research, retrospective hunting in your own telemetry. |
exploitation_chain |
string | The delivery and exploitation mechanism described — zero-click message delivery, network injection, one-click link, physical access — which determines what defence is even possible. | CVE records, vendor security advisories, mobile platform mitigations, detection engineering. |
cve_references |
array | Vulnerabilities identified in the course of the investigation and reported to the platform vendor, where they were subsequently assigned identifiers and patched. | Vulnerability management, EPSS and exploitation status, patch-level assessment of an at-risk device population. |
forensic_method |
string | How the finding was established: consented device forensics, internet-wide scanning, DNS cache probing, network measurement, or code analysis. This determines what the finding can and cannot support. | Methodological assessment; deciding whether a finding is evidence of infection, of targeting, or only of infrastructure existence. |
notification_status |
string | Whether affected individuals, platform vendors or authorities were notified before publication, and what the response was. Frequently the most operationally relevant paragraph in a report. | Platform threat notification programmes, victim support and referral pathways. |
jurisdiction_nexus |
array | Countries implicated as operator, as host of infrastructure, as vendor domicile or as location of targets. These are four different roles and reports distinguish them. | Export control analysis, hosting provider accountability, mutual legal assistance considerations. |
partner_organisations |
array | Collaborating labs, platform security teams and media consortia. Joint publication usually means the finding has been independently corroborated by a second technical team. | Corroborating reports from partners, often with additional indicators the lab did not publish. |
Coverage — and what is not in it
Coverage is deep, narrow and self-selecting. Geographically the lab has published on operators and targets across the Middle East, North Africa, Central Asia, South and Southeast Asia, Europe, Latin America and North America, but the coverage map is not a threat map — it is a map of where civil society networks are strong enough to bring cases forward and where consented forensic access was obtainable. Temporally, the targeted-threats work spans roughly a decade and a half of the commercial spyware industry, with continuity across successive vendor generations that makes it the best available longitudinal record of that market. The network interference work covers a smaller set of countries in far greater technical depth, and the application analysis work concentrates on widely deployed software from jurisdictions with legal data access mandates. Update rhythm is event-driven: reports appear when an investigation concludes, sometimes several in a month and sometimes not for a quarter. Nothing here is continuous, nothing is comprehensive, and the lab says so. What it does offer that no continuous source does is durability — findings published years ago remain accurate as statements about what happened, which is unusual in this field.
Known blind spots
Absence of evidence here is not evidence of absence. These are the conditions under which Citizen Lab will not show you something that is nevertheless real:
- Only cases that reach the lab are investigated. Victims who do not know they are targeted, who are not connected to civil society networks, or who cannot safely surrender a device are invisible, and that population is far larger than the published one.
- Forensic visibility is much better on iOS than on Android, because of the artefacts the platforms retain, so published victim populations skew toward iPhone users in ways that do not reflect the underlying targeting.
- Enterprise and government targets are outside the mandate. Mercenary spyware used against corporate executives, officials or intelligence targets exists and is not covered here, so this source is not a complete picture of the products' deployment.
- Democratic states' lawful interception and intelligence operations are largely absent, both because targets rarely present themselves and because the evidentiary standard for such an attribution is extremely high. Absence is not evidence of restraint.
- Infrastructure findings expire on publication. Vendors monitor these reports and rotate domains, certificates and hosting within days, so an indicator list is a historical record and a hunting aid, not a blocklist.
- Reports are deliberately incomplete. Detection methodology, some indicators and some victim detail are withheld to protect people and to avoid burning capabilities, which means you cannot reproduce every finding from the published material.
- The lag between activity and publication is months to years. This source will never tell you that you are being targeted now; it tells you what a capability did in the past and what to hunt for retrospectively.
- Attribution to a customer is inferential. It rests on infrastructure clustering and targeting patterns rather than on a document or a confession, and the reports state confidence carefully — a nuance that disappears the moment the finding is summarised by anyone else.
- Coverage of the vendor market is uneven. Some companies have been examined repeatedly and others barely at all, which reflects investigative opportunity rather than relative market share or harm.
Write the blind spot into the product. A statement that something “was not observed in Citizen Lab” is defensible; a statement that it “did not happen” is not, and the difference is what survives cross-examination.
Access, licensing and what you may do with it
Access model: Open — no account required
Everything is free and public on the lab's website; there is no registration, key or tier. Indicators, where published, appear in report appendices and sometimes in public repositories, and the lab maintains the URL categorisation lists used by independent censorship measurement in an open repository. There is no feed. Practical monitoring is a matter of watching the publications page, the lab's public accounts and the repositories, and treating each report as an event to be processed rather than a record to be synchronised. For practitioners the more important access question is the other direction: if you are supporting a person who believes they have been targeted, the route is through established civil society support channels — digital security helplines and partner organisations — rather than an unsolicited approach, and the lab's work is consent-based and referral-driven for good reasons. Do not send someone else's device data to a research lab without that person's informed consent.
Licence
Citizen Lab publications carry a Creative Commons licence permitting reuse with attribution; the exact variant is stated on the reports themselves and should be read there rather than assumed, since notices vary across years and across co-published work. Indicators published in appendices and repositories are facts rather than creative works in most legal systems and are freely usable for detection, but attribution remains the professional norm and matters here more than usual — these findings are contested by well-resourced companies, and stripping the provenance from an indicator removes the only thing that makes it defensible. Co-published reports with partner organisations and media consortia may carry additional or different terms. Where you intend to reproduce substantial extracts, or to build a commercial product feature on the lab's findings, read the notice and, if it is ambiguous, ask; a university lab's licensing questions are answered by people, not by a portal.
Rate limits and fair use
There is no API and nothing to rate limit. Do not scrape the site on a tight schedule; publications appear at a cadence measured in weeks and a daily check is already generous. If you mirror indicator repositories, use the ordinary version control mechanisms rather than repeated bulk fetches. The one genuine etiquette point is about attention rather than bandwidth: do not contact researchers for routine data enquiries, and reserve direct contact for cases involving a person at risk.
Licensing changes, and it changes without warning. A dataset that was free for research this year may not be free for commercial or evidential use next year. Confirm the current terms before you build a dependency on it, and record the terms you relied on alongside the data — the licence in force at the time of collection is part of the provenance.
Collecting it
How Citizen Lab is actually pulled, in the order you would set it up. Prefer the bulk or export interface over per-item lookups wherever one exists: it is kinder to the publisher, faster for you, and gives a reproducible snapshot rather than a series of point-in-time answers you cannot reconstruct later.
| Method | Format | Cadence | Notes |
|---|---|---|---|
| Publication monitoring | HTML | weekly | Watch the reports index and process each publication as an intelligence event. Extract the structured elements — family, vendor, operator, targets, indicators, CVEs — into your own records at the time of reading. |
| Indicator repository sync | bulk | on publication | Where indicators are released in a public repository, clone and track it rather than copying values out of a PDF. Preserve the commit history, because it dates when each indicator became public and therefore when it was likely burned. |
| Censorship test list tracking | CSV | continuous | The URL categorisation lists maintained for measurement projects are a separate and underused artefact: they are a curated, per-country view of what is considered sensitive enough to test for blocking. |
| CVE and vendor advisory correlation | JSON | per report | For each report, pull the associated platform vendor advisories and vulnerability records. The patch level of your at-risk device population is the actionable part of most of these findings. |
| Partner corroboration retrieval | HTML | per report | Retrieve the co-published or contemporaneous analyses from partner labs and platform security teams. They frequently contain indicators and detections the lab did not publish. |
Ingesting it into the platform
Every step below is idempotent and cursor-based: interrupt one and it resumes from where it stopped rather than duplicating rows or losing progress. Collection is recorded per source, so a feed that quietly stops publishing shows up as a stale timestamp instead of silently thinning your coverage.
- Register the source as episodic research — Record Citizen Lab in sources.php as a research publisher rather than a feed, with the expected lag between activity and publication noted, so analysts do not treat a quiet month as an absence of threat.
- Create a campaign record per report — Use campaign.php to model each investigation as a named campaign with its vendor, product, operator cluster and target categories, so that indicators attach to an attributed operation rather than floating in a generic pool.
- Import indicators with a burn date — Ingest domains, addresses and hashes through import.php with the publication date recorded as the point of public disclosure, and mark them as historical by default. An indicator published in a report is evidence of what happened, not a live block candidate.
- Resolve infrastructure retrospectively — Run resolve-domains.php and passive-dns.php against published domains to recover their historical resolution, hosting and certificate history — which is where the analytically useful pivots are, since current resolution will be dead.
- Correlate against your own telemetry — Use hunting.php to search historical logs for the published indicators across the full period before publication, not just after. The point of a burned indicator is retrospective detection of a compromise you missed.
- Link vendor and operator entities — Attach the vendor to org-profile.php with its corporate and ownership research, and the operator cluster to country.php and actor-profile.php, so that a technical finding connects to the governance and procurement picture.
- Generate detections where the artefact is durable — Use generate-rules.php to convert durable behavioural artefacts — process names, file paths, exploitation patterns — into Sigma and YARA rules, while deliberately excluding rotated network indicators that would only produce noise.
- Attach to case and referral workflow — Where a finding touches a person your organisation supports, record it in cases.php alongside the referral pathway used, so the technical record and the duty-of-care record stay together.
Registered sources and their last-collected state are listed in sources.php, and the scheduled chain that keeps them current is in automation.php.
How it is wrong, and how to tell
Every dataset is wrong in characteristic ways. Knowing which ways is the difference between using a source and being used by one, and it is the part of source evaluation most often skipped because it is the part that takes work.
Very high on the things it asserts, and that assessment rests on more than reputation. The lab's findings have been repeatedly tested in the most adversarial conditions available: independent corroboration by platform security teams and other forensic labs, vendor legal threats, litigation in multiple jurisdictions, and regulatory processes that used the findings as evidence. They have survived. The methodology sections state what was observed, what was inferred and with what confidence, and the reports are explicit about the limits of scanning-based attribution. Errors, when they have occurred, have been acknowledged. What you must not do is inherit the confidence without the caveats. A statement that a device was infected rests on forensic artefacts and is strong. A statement that a government operates a system rests on infrastructure clustering and targeting patterns and is an inference the report will qualify. A statement about how many people were targeted rests on who came forward and is a floor, never an estimate. The reports draw those distinctions carefully; almost every secondary account of them does not, and if you are working from a news summary rather than the report you are working from a distortion.
Characteristic false positives
- Scanning-derived infrastructure findings can implicate hosting providers and networks rather than operators. A server fingerprint in a country does not mean the customer is in that country, and reports are careful about this in ways that summaries are not.
- Indicator lists go stale immediately on publication because vendors read these reports. Blocking on them produces a false sense of coverage while the live infrastructure has already moved.
- Domains and addresses are reused. An IP address that hosted spyware infrastructure two years ago may now host something entirely unrelated, and alerting on it today generates confident, wrong incidents.
- Absence of a forensic finding is not absence of compromise, particularly on Android and particularly for older infections where the artefacts have been overwritten. A clean forensic result is a weaker statement than victims and journalists usually understand it to be.
- Targeting is confused with infection. Many reports document attempted delivery — a message, a link, a network injection — which establishes intent but not success, and the two get merged in retelling.
- Operator attribution is read as agency attribution. A cluster attributed to a country is not attributed to a named service, and treating it as such creates a claim the report does not support and will not defend.
- Vendor product naming collides. The same capability appears under a vendor product name, a lab-assigned name and several antivirus detection names, and joining across them without a mapping merges or splits families incorrectly.
- Publication timing is mistaken for event timing. A report released this quarter frequently describes targeting from one or two years earlier, and building a timeline on publication dates inverts the actual sequence of events.
None of these make the source unusable. They make it a source that requires corroboration before an assertion built on it goes into a product, which is true of every source and admitted by few.
Ageing
Findings and indicators age at opposite rates, and confusing them is the standard error with this source. The findings do not age: a documented infection of a named journalist's device in a given year remains true indefinitely, and the exploitation chain and forensic artefacts remain valuable as detection knowledge long after the specific infrastructure is gone. The network indicators age in days. Publication is itself the burn event — vendors monitor these reports and rotate — so a domain list is at its least useful the moment it becomes public and at its most useful when applied backwards across your own historical telemetry. Vendor and operator information ages at an intermediate rate: companies rebrand, restructure, relocate to friendlier jurisdictions and are acquired, and government customers change agencies and procurement arrangements. A stale usage looks like a blocklist populated from a three-year-old appendix, or a threat briefing that names a vendor entity that has since been dissolved and reconstituted. Re-derive vendor corporate detail at the point of use, and treat every published indicator as a hunting query rather than a control.
What this source feeds
A source is only worth what it lets you conclude. These are the disciplines that collect through it, the mission domains it serves and the data points it yields — every one is a tag, so you can follow any thread from here into the rest of the library.
Collected by these intelligence disciplines
Serves these mission domains
Yields these data points
How each sector uses Citizen Lab
The same dataset is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The records are shared — the constraints, thresholds and outputs are not.
🎖 Military and defence
Two uses, both defensive. The first is force protection in the information sense: personnel, contractors and their families operating in or travelling to countries with documented mercenary spyware deployments face a real and specific mobile device threat, and these reports establish which capabilities exist, how they are delivered and what mitigations actually work. Zero-click delivery changes the defensive calculus entirely, and the platform hardening measures documented in this research are the practical response. The second is understanding an adversary's or a partner's capability acquisition: which states have bought which products, from which vendors, under which export approvals, is a genuine order-of-battle question for information operations and counterintelligence. Treat the reports as capability documentation rather than as warning; the lag is too long for anything else, and the mandate excludes exactly the state actors most likely to be of operational interest.
🕵 National intelligence
This is open-source counterintelligence material of unusually high quality, and it is one of the few places where commercial surveillance capability is documented to an evidentiary standard. Use it for three things: mapping the vendor market and its customer base as a proliferation problem; understanding the technical delivery chains well enough to assess your own exposure; and calibrating what a government's spyware procurement says about its priorities and its internal security architecture. The attribution discipline in these reports is worth studying in its own right — the way confidence is expressed and bounded is a model that most intelligence writing would benefit from. The structural caution is the mandate: the lab investigates threats to civil society, not to states, so its silence about a capability or an operator carries no information about whether one exists.
👮 Law enforcement
Investigators encounter this material in two roles that must not be confused. In the first, mercenary spyware deployed against journalists, lawyers or exiles inside your jurisdiction is a crime — unauthorised computer access, interception, and in some framings an act of foreign interference — and Citizen Lab reports have been the predicate for exactly such investigations. The lab's forensic findings are research products rather than evidence collected under your rules; where a case follows, you need your own lawfully obtained forensic examination, and the report is what justifies seeking it. In the second role, agencies are themselves customers of surveillance vendors, and these reports document the accountability failures that follow when such tools are used outside a warrant framework. The professional position in both cases is the same: this is a source about the lawful basis for intrusive capability, and it should inform how your own is governed.
🔍 Private investigation and corporate security
For corporate investigations and executive protection, the relevance is that mercenary spyware is a commercial product available to state customers who use it against business counterparties, litigation adversaries and journalists reporting on companies. If a client is engaged in a dispute with a state-linked entity, or is a journalist or activist your firm supports, these reports define the realistic threat model and the mitigations. Do not, however, use them as a diagnostic: telling a client they are infected on the basis of a symptom described in a report is irresponsible, and mobile forensic assessment requires specialist capability and the client's informed consent. Refer to the established civil society support channels where the subject qualifies, and to a competent commercial forensics provider where they do not. And be aware of the mirror image: this research has repeatedly documented private intelligence firms attempting to compromise or entrap researchers and their sources, which is a professional conduct boundary the industry has not always respected.
📰 Journalism and OSINT media
For journalists, Citizen Lab is both a source and, uncomfortably often, a subject — reporters are among the most consistently documented targets of these capabilities. As a source, it supplies technically verified findings that can be reported with confidence, along with researchers who will explain what the evidence does and does not show. Read the report rather than the press release, and preserve the confidence language: the difference between 'was targeted' and 'was infected', and between an operator cluster and a named agency, is the difference between a defensible story and a retraction. As a subject, take the findings personally and operationally: if you work on organised crime, corruption or state repression, the threat model in these reports is your threat model, and the platform hardening measures they describe are the minimum professional standard. Protect sources accordingly, and route any suspected targeting through a digital security helpline rather than social media.
🌍 NGO, humanitarian and human rights
Human rights organisations are the constituency this work exists for, and the most important thing to take from it is not the indicators but the referral pathway. If a staff member or a partner believes they have been targeted, there are established civil society digital security helplines and forensic support channels; use them, and do not attempt device forensics in-house on a device that may hold evidence. Organisationally, the reports justify a security posture that would otherwise be dismissed as paranoid: zero-click exploitation means that user training does not protect you, and platform-level hardening, device replacement policies and compartmentation do. For advocacy work, the findings are the evidentiary basis for export control submissions, litigation, UN special procedure communications and shareholder engagement with investors in the vendors. Handle victim identities with the same care the lab does: nothing is published without informed consent, and consent given for one publication is not consent for another.
🎓 University and research
The lab is itself an academic institution and its reports are citable research, but they are unusual in the field for combining device forensics, internet measurement, legal analysis and area expertise in one product. For researchers, the corpus supports work on the political economy of the surveillance industry, on the effectiveness of export control regimes, on the sociology of transnational repression and on measurement methodology itself. The methodological caution for quantitative work is severe selection bias: the victim population is a convenience sample of people who came forward and could safely be examined, so no prevalence claim is supportable from it. The censorship test lists are a separate and valuable research artefact with their own methodological literature. Anyone doing research on identified victims should note the ethics standard the lab applies — informed consent, control over publication, and a recognition that publication itself can create risk — and match it.
Playbook: working Citizen Lab end to end
A repeatable sequence from first pull to finished product. Each phase states what you are trying to establish, not merely what to click — the objective is a defensible chain of reasoning, not a completed checklist.
Phase 1 — Establish which question the report answers
Before extracting anything, determine whether a given finding concerns infrastructure, targeting or confirmed infection. These three rest on different evidence and support different claims. Reports state which is which; secondary coverage almost never does, and starting from a news article rather than the report is the single most common way this source is misused.
Phase 2 — Extract the structured elements immediately
Convert each report into records at the time of reading: vendor, product family, operator cluster with its stated confidence, target categories, jurisdictions in each of their four roles, indicators, CVEs and notification status. Doing this later means doing it from memory, and the confidence qualifiers are the first thing lost.
Phase 3 — Date the activity, not the publication
Build your timeline from the incident dates in the report body. Publication typically lags targeting by many months, and a timeline built on publication dates will show a wave of activity that is actually a wave of disclosure.
Phase 4 — Hunt backwards before you block forwards
Run every published indicator against your own historical telemetry across the full period preceding publication. This is where burned indicators earn their value — as retrospective detection of compromise you did not notice — and it is a strictly time-limited opportunity because log retention runs out.
Phase 5 — Recover the infrastructure history
Pull passive DNS, certificate transparency and hosting history for published domains and addresses. Current resolution will be dead; the historical record is where you find sibling infrastructure, registration patterns and the operator's tradecraft, which outlive any single domain.
Phase 6 — Assess your own exposure against the exploitation chain
Map the delivery mechanism described onto your organisation's device estate: platform versions, patch levels, messaging applications in use, and whether the hardening modes documented in this research are enabled for at-risk staff. Zero-click delivery means awareness training is not a control and should not be counted as one.
Phase 7 — Separate what you can act on from what you can only know
Distinguish findings that change a technical control from findings that change a risk judgement. Most of this research does the latter. Products that treat every report as a detection engineering task generate noise; products that treat none of them that way miss the retrospective hunt.
Phase 8 — Research the vendor as a corporate entity
Take the vendor name into corporate registries, beneficial ownership data, investor disclosures and export control listings. The surveillance industry restructures continuously to stay ahead of designation, and the entity in a three-year-old report is frequently not the entity operating today.
Phase 9 — Place the operator in its governance context
Attach the operator cluster to the country's legal framework for interception, its record of transnational repression, and its documented procurement. A capability finding becomes an intelligence judgement only when you can say who is authorised to use it and against whom, and whether that authorisation was followed.
Phase 10 — Handle any human subject through a referral pathway
If your work touches an individual who may have been targeted, stop and route them to an established civil society digital security channel before doing anything technical. Do not examine a device without informed consent, do not publish an identity, and do not let an investigative interest override the person's own risk assessment.
Phase 11 — Cross-check against partner publications
Retrieve contemporaneous analyses from partner forensic labs, platform security teams and media consortia. Independent corroboration strengthens the finding, and partners frequently publish indicators or detections that the lab withheld.
Phase 12 — Record with provenance and confidence intact
Store findings in cases.php and reports.php with the report citation, the lab's confidence language quoted rather than paraphrased, and the distinction between infrastructure, targeting and infection preserved. These findings get litigated; a record that has flattened the qualifiers is a liability rather than an asset.
The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.
What to pair it with
No single source carries a finding. These are the datasets that corroborate, extend or contradict this one — and a source that contradicts is worth more than one that agrees, because it is the only thing that will tell you when you are wrong.
| Source | Relationship | What it adds |
|---|---|---|
| Amnesty International Security Lab | corroborates | The other major public-interest forensic team working on mercenary spyware, frequently co-publishing and maintaining open forensic tooling for consented device analysis. |
| Google Threat Analysis Group | corroborates | Platform-side visibility into commercial surveillance vendors, exploitation chains and targeting, published from a vantage point no external lab has. |
| Microsoft Security Blog | corroborates | Analysis of surveillance vendor tooling on Windows and cloud platforms, including joint work with Citizen Lab on specific vendors. |
| OONI | extends | Open censorship measurement that consumes the lab's URL test lists, turning the categorisation work into continuous global measurement of what is blocked where. |
| Access Now | prerequisite | Operates the digital security helpline that is the correct first contact for a person at risk. In a case involving a human subject, the referral pathway comes before the technical work. |
| Electronic Frontier Foundation | extends | Legal and policy analysis of surveillance technology, litigation, and practical security guidance for at-risk users that translates forensic findings into user action. |
| Bureau of Industry and Security | extends | United States export control administration, including entity listings that have designated surveillance vendors on the basis of research of this kind. The regulatory consequence of the findings. |
| Freedom House | extends | Country-level assessment of internet freedom and transnational repression, providing the governance context in which a documented deployment should be read. |
| Citizen Lab repositories | extends | Public code and data repositories, including the censorship test lists and, for some investigations, indicator releases with commit history that dates disclosure. |
Legal, ethical and operational constraints
The findings are lawfully published research and using them is unproblematic; the legal risk lies in what you do next. Three areas need care. First, defamation and vendor litigation: surveillance companies have pursued legal action against researchers and publishers, and repeating an attribution without the lab's qualifying language converts a carefully bounded finding into a stronger claim that you, not the lab, would have to defend. Quote the confidence, do not upgrade it. Second, personal data: victim identities, target categories and device forensic artefacts are personal data in most regimes, frequently special-category data given the political and religious dimensions, and re-publishing or re-identifying individuals whom the lab published with consent or anonymised is both unlawful in many places and dangerous everywhere. Third, forensic examination: analysing a device requires the informed consent of its owner, and in an employment context consent obtained under duress is not consent. If a matter may become a criminal case, an unlawfully or carelessly obtained examination can destroy its admissibility. The correct sequence is always referral, consent, then analysis.
Operational security
Reading public research from a university website is unremarkable in most environments and not in all of them; in states that treat contact with foreign human rights organisations as a security matter, patterned access from inside the country is an exposure for the reader rather than for the lab. More significant is what your subsequent activity reveals. Resolving published spyware domains, requesting certificate histories or scanning related infrastructure are observable actions, and operators who monitor their own indicators can infer that a particular network has read the report and is hunting. Use passive sources rather than active probing where the distinction matters, and separate research infrastructure from operational networks. Be aware too that this research area attracts targeted deception: the lab has documented private operatives approaching researchers under false identities to extract information about ongoing work, and anyone visibly working in this space should expect the same. Treat unsolicited approaches offering collaboration, funding or victim contacts as a threat vector, and verify independently.
Two rules that hold regardless of jurisdiction. Collection that is lawful is not automatically proportionate, and a dataset assembled for one purpose does not carry consent for another. Where the records concern identifiable people, the question is not only whether you may hold the data but whether holding it serves the purpose you are accountable for.
Is it earning its place?
Sources accumulate. Feeds get added during an incident and are never reviewed again, and a decade later the pipeline is carrying dead weight that nobody dares remove. These are the measures that show whether Citizen Lab is contributing anything, and they are worth baselining now so the answer is available later.
- Time from report publication to completion of a retrospective hunt across your own telemetry, measured against your log retention window, since the opportunity expires when the logs do.
- Number of historical compromises or targeting attempts discovered in your own environment by hunting published indicators backwards, which is the only direct measure of value this source returns.
- Proportion of at-risk devices in your estate running current platform versions with the documented hardening measures enabled, tracked as the control that actually addresses this threat class.
- Count of findings recorded with the lab's confidence language preserved intact, versus those flattened into stronger claims during internal summarisation.
- Number of vendor entities in your records re-verified against current corporate and export control data within the last year, since the industry restructures faster than reports are written.
- Referrals made through established digital security channels for individuals your organisation supports, and the time taken to make them, as the duty-of-care measure that matters more than any technical metric.
- Detection rules derived from durable behavioural artefacts as a share of those derived from rotating network indicators, as an indicator of whether your detection engineering understands the difference.
Beware of volume. Indicator counts rise easily and say almost nothing. Unique contribution — findings this source produced that no other source in your stack would have — is the measure that matters, and it is usually far lower than anyone expects.
Tradecraft notes
The distinctions that separate a competent analyst from a fast one:
- Read the report, not the coverage. Every important qualifier in this research — targeted versus infected, cluster versus agency, observed versus inferred — survives in the original and is destroyed in summary.
- Publication is the burn event. Plan your use of indicators around the fact that the adversary read the same report you did, on the same day, and moved.
- Hunt backwards. The single highest-value action on a new report is a retrospective search of historical telemetry, and it has a deadline set by your log retention rather than by anyone's urgency.
- A clean forensic result is weak evidence of safety, especially on Android and especially for older infections. Communicate that honestly to anyone who has asked you whether their phone is compromised.
- Distinguish the four jurisdictional roles — vendor domicile, operator, infrastructure host, target location — because conflating them produces attributions that are geographically confident and analytically wrong.
- Vendor corporate identity is a moving target. Re-derive it from registries and ownership data at the point of use rather than citing the entity named in an older report.
- Zero-click delivery invalidates awareness training as a control. Any risk assessment that still counts user vigilance against this threat class is describing a different threat.
- Never let an investigative interest override a subject's own risk assessment. The person being targeted knows things about their situation that your analysis does not, and the referral pathway exists precisely so that the technical work does not lead the duty of care.
- Watch what the absence of coverage means. This lab investigates threats to civil society; silence about a state or a product tells you about investigative opportunity, not about the world.
Questions analysts actually ask
Can I subscribe to Citizen Lab indicators as a feed?
No. Indicators appear in report appendices and occasionally in public repositories, irregularly and incompletely. Monitor publications and process each as an event. If your architecture requires a feed, this source will not fit it, and forcing it to will produce a stale list that looks like coverage.
Should I block the domains published in a report?
You can, but expect no benefit. The infrastructure is rotated on publication. The real value is retrospective: search your historical logs for those indicators across the period before the report, where a hit means an intrusion you missed.
How reliable is the attribution to a specific government?
The reports attribute deployments to operator clusters with a stated confidence, based on infrastructure and targeting patterns rather than on documentary proof. That is usually strong enough to act on and rarely strong enough to name a specific agency. Preserve the lab's wording; do not upgrade it.
Someone I work with thinks their phone is infected — what do I do?
Route them to an established civil society digital security helpline before doing anything technical, and do not examine the device without their informed consent. Preserve the device rather than resetting it. If the matter may become a legal case, an improvised examination can destroy its evidentiary value.
Why do so many documented victims use iPhones?
Largely because iOS retains forensic artefacts that make infection detectable, while equivalent evidence on Android is frequently unrecoverable. The published victim population reflects what can be proven, not what is targeted, and reading it as a platform security comparison gets the inference backwards.
Does the lab investigate spyware used by democracies?
Rarely, and its silence is not evidence. Its mandate is threats to civil society and its cases arrive through civil society networks; targets of lawful interception in democratic states seldom present themselves for forensic analysis, and the evidentiary bar for such an attribution is very high.
Can I cite these reports in a legal filing or regulatory submission?
They have been used that way extensively, including in export control and litigation contexts. Cite the report itself, preserve its confidence language, and understand that it is expert research rather than evidence gathered under your rules of procedure — you will usually need your own forensic work as well.
How current is the technical detail?
The exploitation chains and forensic artefacts remain instructive for years; the network infrastructure is obsolete on publication. Treat the methodology as durable knowledge and the indicators as a dated snapshot, and never let the two share a shelf life in your records.
What are the censorship test lists and why should I care?
They are curated, per-country lists of URLs considered sensitive enough to test for blocking, maintained openly and used by independent measurement projects. They are a useful artefact in their own right: a structured statement of what is contested in a given country, maintained by people with local knowledge.
Standards, formats and interoperability
What this source speaks natively, and what it has to be translated into before a partner can consume it. Work that arrives in a recognised format is easier to defend, easier to hand over and easier to automate against:
- CVE identifiers link the lab's vulnerability discoveries to the platform vendors' advisories and to your own patch management, and are the most directly actionable output of the targeted-threats work.
- MITRE ATT&CK, and particularly its mobile matrix, is the natural framework for mapping the exploitation chains and post-compromise behaviour these reports document.
- Open forensic tooling maintained by partner organisations for consented mobile device analysis is the practical standard for examining a device against published indicators, and should be used rather than improvised.
- The lab's URL categorisation test lists are the de facto standard input to independent censorship measurement and are maintained as open data with a documented category taxonomy.
- Coordinated vulnerability disclosure to platform vendors is the lab's standard practice, which is why findings frequently arrive alongside a patch rather than ahead of one.
- Research ethics review and informed consent govern all work involving human subjects here, and any downstream use of victim material inherits those obligations rather than escaping them.
- The platform exports indicators and campaign entities derived from these reports in STIX 2.1, MISP, YARA and Sigma, with the source report retained as provenance on every object.
- Nothing derived from these reports in the platform is model-generated: indicators and relationships come from the published research, and Copilot summaries describe records that already exist.
References
Primary documentation and authoritative references for this source. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.
- The Citizen Lab — Munk School of Global Affairs and Public Policy, University of Toronto. The primary source: all reports, methodology sections and technical appendices. Always work from here rather than from secondary coverage.
- Citizen Lab on GitHub — The Citizen Lab. Public repositories including the censorship test lists and, for some investigations, indicator releases whose commit history dates disclosure.
- Amnesty International Security Lab — Amnesty International. The principal partner forensic team, with open tooling for consented device analysis and frequently corroborating publications.
- Google Threat Analysis Group — Google. Platform-side reporting on commercial surveillance vendors and exploitation, from a vantage point external researchers cannot reach.
- Microsoft Security Blog — Microsoft. Vendor tooling analysis including joint investigations with the lab, and the detection guidance that follows.
- OONI — Open Observatory of Network Interference. The measurement project that operationalises the lab's censorship test lists into continuous global data on what is blocked where.
- Access Now — Access Now. Operator of the digital security helpline that is the correct referral route for an individual who believes they have been targeted.
- Electronic Frontier Foundation — EFF. Legal, policy and practical security analysis that turns forensic findings into user-facing guidance and litigation.
- Bureau of Industry and Security — United States Department of Commerce. Export control administration and entity listings, the regulatory mechanism through which this research has had material effect on the vendor market.
- Freedom House — Freedom House. Country-level internet freedom and transnational repression assessments providing governance context for a documented deployment.
- Munk School of Global Affairs and Public Policy — University of Toronto. The institutional home, which is the reason the lab operates under academic freedom protections and a research ethics regime.
Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.
Put it into practice
The Quantus Intel threat intelligence platform operationalises this source: it turns each published investigation into a campaign record with its vendor, operator cluster and target categories intact, drives published indicators backwards through your own telemetry as a retrospective hunt, recovers the historical infrastructure around them through passive DNS and certificate history, and keeps the lab's confidence language attached to every derived claim.. Browse the full source catalogue, or follow any tag above into the rest of the library.