QSpy: A Quantum RAT for Circuit Spying and IP Theft

As quantum computing platforms increasingly adopt cloud-based execution, users submit quantum circuits to remote compilers and backends, trusting that what they submit is exactly what will be run. This shift introduces new trust assumptions in the submission pipeline, which remain largely unexamined. In this paper, we present QSpy, the first proof-of-concept Quantum Remote Access Trojan capable of intercepting quantum circuits in transit. Once deployed on a user’s machine, QSpy silently installs a rogue certificate authority and proxies outgoing API traffic, enabling a man-in-the-middle (MITM) attack on submitted quantum circuits. We show that the intercepted quantum circuits may be forwarded to a remote server, which is capable of categorizing, storing, and analyzing them, without disrupting execution or triggering authentication failures. Our prototype targets IBM Qiskit APIs on a Windows system, but the attack model generalizes to other delegated quantum computing workflows. This work highlights the urgent need for submission-layer protections and demonstrates how even classical attack primitives can pose critical threats to quantum workloads.

💡 Research Summary

The paper “QSpy: A Quantum RAT for Circuit Spying and IP Theft” investigates a previously under‑explored attack surface in cloud‑based quantum computing: the submission pipeline that carries user‑generated quantum circuits from a client machine to a remote quantum backend. As quantum hardware remains expensive and fragile, most users rely on services such as IBM Quantum, Amazon Braket, Azure Quantum, or IonQ, submitting circuits via SDKs (e.g., Qiskit) over HTTPS/TLS. The authors argue that while the execution itself is remote, the circuit data traverses a classic client‑server channel and therefore inherits the same trust assumptions and vulnerabilities as conventional cloud services.

To demonstrate the feasibility of exploiting this trust boundary, the authors develop QSpy, a proof‑of‑concept Quantum Remote Access Trojan. QSpy assumes the attacker can run user‑level code on the victim’s workstation (through social engineering, compromised development environments, or malicious tooling) but does not have any privileged access to the quantum provider or the ability to break cryptographic primitives. The core of the attack is the insertion of a malicious root certificate into the operating system’s trusted store, which enables a local man‑in‑the‑middle (MITM) proxy (implemented with mitmproxy) to terminate TLS sessions, inspect the clear‑text payloads, and then re‑encrypt the traffic before forwarding it to the legitimate quantum service.

The workflow mirrors the standard asynchronous job model used by most quantum clouds: (1) the client serializes a circuit and sends a POST /​jobs request; (2) the service immediately returns a job identifier; (3) the client later polls a GET /​jobs//results endpoint to retrieve measurement outcomes. QSpy passively records the serialized circuit from the POST request, buffers it, and upon receipt of the job_id in the response binds the two together. When the corresponding result response arrives, QSpy attaches the result payload to the same record, producing a complete tuple (job_id, circuit_payload, submission_metadata, results_payload, timestamps). This tuple is then exfiltrated to an attacker‑controlled command‑and‑control server. Crucially, QSpy never modifies the request or response, so from the user’s perspective the execution proceeds exactly as if no interception were present; no errors, delays, or TLS warnings are observed.

The prototype targets IBM Qiskit APIs on a Windows platform, but the authors argue that the same technique applies to any cloud quantum service that follows the same submission‑and‑poll pattern, regardless of the underlying hardware (superconducting, ion‑trap, etc.) or operating system. The paper includes a video demonstration and releases the source code publicly.

Key contributions are:

1. The first concrete demonstration of a quantum‑specific Remote Access Trojan capable of silently harvesting quantum circuits and their results.
2. Empirical evidence that existing TLS‑based authentication and JWT‑based authorization do not protect the payload once the client’s trust store is compromised.
3. A clear articulation of the threat model, showing that an attacker need only limited local privileges to achieve full visibility into a user’s quantum intellectual property.

The authors discuss several limitations. The current implementation is confined to Windows and the Qiskit SDK; macOS, Linux, and alternative SDKs (e.g., Braket Python SDK, Azure Quantum) have not been experimentally validated. The attack does not perform active circuit tampering; it merely records data, leaving the question of how to inject malicious modifications unanswered. Performance overhead is not quantified, especially for large‑scale jobs with many qubits or deep circuits.

In the discussion, the paper highlights the urgent need for end‑to‑end protection of quantum workloads. Potential mitigations include: (a) client‑side encryption or digital signatures of circuit payloads before transmission, (b) hardware‑rooted trust (TPM, Secure Enclave) to protect the certificate store, (c) server‑side verification of circuit integrity (e.g., hash commitments), and (d) tighter policies around SDK installation and environment hardening. The authors also call for collaboration between quantum service providers and the broader security community to develop standards for quantum‑specific data confidentiality.

Overall, QSpy demonstrates that classical attack primitives—MITM, rogue CAs, and RATs—remain potent threats in the emerging quantum computing ecosystem. By exposing the vulnerability of the submission layer, the work urges a re‑examination of security assumptions and motivates the development of quantum‑aware confidentiality mechanisms to safeguard valuable quantum algorithms and IP.