Frequently Asked Questions

Yes, our reports are designed for legal admissibility. We follow internationally recognized forensic standards:

• NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response
• ISO/IEC 27037 — Guidelines for identification, collection, acquisition and preservation of digital evidence
• RFC 3227 — Guidelines for Evidence Collection and Archiving

Every report includes SHA256 hashes, chain of custody documentation, and packet-level references for each finding. However, admissibility ultimately depends on jurisdiction and the presiding court. We recommend consulting with legal counsel familiar with digital evidence in your jurisdiction.

Chain of custody is tracked cryptographically from capture to report:

• Collection: PCAP files are hashed (SHA256) immediately upon capture
• Transfer: All uploads occur over TLS 1.3 with certificate pinning
• Storage: Evidence is stored in immutable storage with access logging
• Analysis: Each processing step is logged with timestamps and operator ID
• Export: Final report includes complete custody chain as appendix

Each custody event is cryptographically linked to the previous event, creating a blockchain-like integrity chain. Any break in the chain is immediately detectable.

Our analysis methodology is built on the OIHL Framework (Observation-Interpretation-Hypothesis-Likelihood), which ensures forensic conclusions are defensible:

This framework prevents over-interpretation and ensures we never present speculation as fact. Every conclusion shows the underlying evidence and alternative hypotheses considered.

Spyware must communicate. Even the most sophisticated surveillance tools need to:

• Exfiltrate collected data (contacts, messages, location, recordings)
• Receive commands from operators (what to collect, when to activate)
• Send heartbeats to confirm the implant is active

We detect these communications through multiple correlation methods:

• IOC Matching: Known C2 IPs, domains, and URLs from 10+ threat intel feeds
• JA3/JA4 Fingerprints: TLS client fingerprints unique to specific spyware families
• Certificate Analysis: Anomalous certificate chains, self-signed certs, unusual issuers
• Behavioral Analysis: Beacon timing, data volume patterns, protocol anomalies
• Temporal Correlation: Suspicious activity timing relative to user behavior

JA3 is a method of fingerprinting TLS clients based on the Client Hello packet. Every application has a unique way of initiating TLS connections — the cipher suites offered, extensions used, and their order create a fingerprint.

JA4+ is the next generation, providing more granular fingerprints:

• JA4 — Enhanced client fingerprint (more collision-resistant than JA3)
• JA4S — Server Hello fingerprint
• JA4H — HTTP request fingerprint
• JA4T — TCP fingerprint
• JA4X — X.509 certificate fingerprint

We use the complete JA4+ suite from FoxIO's JA4DB, combined with SSLBL's JA3 blacklist, to identify malicious traffic even when encrypted.

Attribution is only reported when we have high-confidence indicators.

We attribute to specific spyware families (e.g., "Pegasus", "Predator") only when:

• IOC matches known infrastructure from Citizen Lab, Google TAG, Amnesty Tech, or similar authoritative sources
• JA3/JA4 fingerprint matches documented samples
• Certificate chain matches known spyware vendor patterns
• Multiple independent indicators correlate

For behavioral-only detections (suspicious patterns without IOC match), we report the threat category (e.g., "Stalkerware-like beaconing", "Data exfiltration pattern") without claiming specific attribution. This prevents false accusations while still alerting to genuine threats.

Our multi-engine correlation approach minimizes false positives:

• IOC-based detections: Very low FP rate (~0.1%) — these are known-bad indicators
• JA3/JA4 fingerprint matches: Low FP rate (~1%) — fingerprints are highly specific
• Behavioral detections: Moderate FP rate (~5%) — patterns can have legitimate explanations

To further reduce false positives:

• We maintain a Tranco Top 1M whitelist of legitimate domains
• We exclude known CDN and cloud provider IP ranges
• Every finding shows confidence scores and alternative hypotheses

We prioritize accuracy over alerting volume. A "clean" scan is not a failure — it means no indicators were found.

Every finding is mapped to MITRE ATT&CK v18.1 (both Enterprise and Mobile matrices), providing:

• Technique IDs: Standardized identifiers (e.g., T1437.001 - Application Layer Protocol)
• Tactic Context: Where the technique fits in the attack lifecycle (C2, Exfiltration, etc.)
• Kill Chain Phase: Lockheed Martin Cyber Kill Chain mapping
• Severity Weighting: Techniques are weighted by their tactical impact

This standardization allows:

• Integration with SIEM and SOAR platforms that understand ATT&CK
• Comparison with other threat reports using the same taxonomy
• Clear communication with security teams globally

A complete scan consists of two phases:

1. Network Capture: 10 minutes (default)

• Default capture duration to detect C2 beaconing patterns
• Configurable: 5 min (quick triage) to hours/days (dormant threats)
• 10 min recommended because spyware typically beacons every 1-5 minutes

2. Analysis: 1-5 minutes (varies)

• Depends on PCAP size and content complexity
• Small capture (<1 GB): ~1 minute
• Large capture (1-10 GB): 2-5 minutes
• Very large (10+ GB): may take longer

Total: <15 minutes for standard scans (10 min capture + ~5 min analysis).

Analysis engines run in parallel: Zeek protocol analysis, Suricata signatures, behavioral analysis, JA3/JA4 fingerprinting, and threat intelligence correlation.

Feeds are updated automatically on different schedules based on source update frequency:

• Every 6 hours: SSLBL (JA3, certs, IPs), Feodo, URLhaus, ThreatFox
• Daily: Government Spyware IOCs, Emerging Threats, Spamhaus DROP, Tranco whitelist
• Weekly: JA4DB (FoxIO)

All feeds run via systemd timers with automatic failure retry. The database currently contains 50,000+ active IOCs.

Reports can be exported in multiple formats:

• PDF Report: Complete analysis with executive summary, technical details, and chain of custody
• STIX 2.1 Bundle: Machine-readable threat intelligence for SIEM/SOAR integration
• JSON: Raw findings data for custom processing
• HTML: Interactive report for browser viewing

STIX 2.1 bundles are compatible with MISP, OpenCTI, Splunk ES, Microsoft Sentinel, and other platforms.

Data retention depends on your plan:

• Professional: PCAP files are automatically deleted after 30 days. Reports retained for 1 year.
• Enterprise: Configurable retention (30 days to indefinite). On-premise deployment available.

You can request immediate deletion at any time. We never share your data with third parties (except as required by law). All data is encrypted at rest using AES-256.

Not directly. Zero-day exploits by definition have no known signatures. However, we can often detect the post-exploitation activity:

• Unusual C2 communication patterns (new infrastructure, but similar behaviors)
• Data exfiltration anomalies (volume, timing, destination)
• Certificate anomalies (self-signed, unusual issuers)
• Protocol violations or unusual TLS configurations

If a zero-day implant communicates with known infrastructure or uses similar TLS configurations to known malware, we may still detect it. But we cannot guarantee detection of entirely novel threats.

This is a known evasion technique called domain fronting or CDN hiding. Sophisticated spyware may route traffic through CloudFront, Fastly, or Google infrastructure to blend with legitimate traffic.

Our detection capabilities in this scenario:

• Can detect: Unusual certificate chains, timing anomalies, volume patterns inconsistent with normal CDN usage
• May miss: Perfect domain fronting with clean certificates and normal-looking patterns

We are transparent about this limitation. If you suspect CDN-based evasion, we recommend combining network analysis with device-level forensics for comprehensive coverage.

A clean scan means no indicators were found in the captured traffic — not that your device is definitively uncompromised.

A clean result could mean:

• The device is genuinely clean
• Spyware was present but not active during the capture window
• Spyware uses infrastructure we don't have signatures for
• Traffic was captured before infection occurred

For high-assurance scenarios, we recommend:

• Extended capture periods (24-72 hours minimum)
• Multiple scans over time
• Combining with device-level forensics (filesystem analysis, memory forensics)