Local Detection of Spyware Indicators & Compromise Signals
Threat Shield is a local detection engine that scans a device for known indicators consistent with Pegasus-class compromise, Predator, FinSpy, and commercial stalkerware, then escalates a response in proportion to what it finds. It is written, reviewed, and — as of this release — not switched on.
Status: implemented, not enabled in the shipping client
Threat Shield is never started by the Railgun desktop app. The engine is constructed only through a factory that nothing calls, the Electron main process does not import it, and the warning banner in the app is wired to a report that is always empty. No scan runs, no indicator is evaluated, and no lockdown can fire on a client you can download today.
Everything below describes the engine as written, so that it can be reviewed on its merits and so the gap is on the record. Treat it as a design document for a feature in progress — not as protection you currently have. If your threat model includes Pegasus-class targeting, use Amnesty International's MVT and professional forensic help today; do not wait on this.
Why This Matters
NSO Group's Pegasus can silently intercept messages before encryption by reading the screen, logging keystrokes, or accessing the microphone and camera. End-to-end encryption is meaningless if the endpoint device is compromised. Threat Shield is an attempt at the endpoint half of the problem — which is why it is being built, and why shipping it unwired is a real gap rather than a cosmetic one.
What Threat Shield Can and Cannot Do
Threat Shield is a risk engine, not a magic oracle. Once enabled it would raise the cost and complexity of attacking a Railgun user, but no software can guarantee detection of every possible compromise. Here is an honest accounting of the engine's design ceiling — on top of which, today, it is not running:
Can detect many known indicators of compromise (IOCs) and suspicious runtime conditions — once a client starts it.
Can catch some forms of interception, instrumentation, hostile environment tampering, and C2 communication.
Can escalate response proportionally — from a warning through to full lockdown — based on composite evidence.
Cannot guarantee detection of every zero-click or in-memory implant. Sophisticated attackers with nation-state resources can develop novel techniques that evade known indicators.
A “clear” result is not proof that a device is clean. It means no known indicators were found at the time of the scan.
Does not run at all today. No shipping Railgun client starts the engine, so in practice it currently detects nothing.
1. Detection Architecture
Threat Shield uses a two-layer defense model, inspired by the approach used by Amnesty International's MVT (Mobile Verification Toolkit), adapted for real-time desktop detection. A third component, Update Shield, is designed to gate the update mechanism on device health; the auto-updater does not call it yet.
Layer 1: Static
File artifacts, certificates, process enumeration, stalkerware detection, debugger & injection checks. Runs on every app launch. ~50ms.
Layer 2: Behavioral
C2 network connection monitoring, CPU usage anomalies, suspicious listening ports, library injection detection. Runs every 15 minutes.
Update Shield (not wired)
Designed to block updates on a compromised device and to verify the binary against a SHA-256 manifest and an Ed25519 signature. Nothing in the auto-updater calls it yet.
Each layer produces a set of Threat Indicators — individual findings with a severity score. These are aggregated into a final Threat Level that determines the app's response.
2. Layer 1: Static Indicator Analysis
On every launch, Threat Shield checks for known Indicators of Compromise (IOCs) — file paths, process names, and certificate anomalies that are known signatures of specific spyware families.
File Artifact Scanning
Pegasus and similar spyware leave traces in predictable locations. These are derived from Amnesty International's MVT database and Citizen Lab research:
// macOS — Pegasus persistence via LaunchAgents
~/Library/LaunchAgents/com.apple.icloud.searchpartyd.plist
~/Library/LaunchAgents/com.apple.assistantd.plist
// Pegasus staging directories (from MVT forensic analysis)
/private/var/tmp/BridgeHead
/private/var/tmp/.spotlightextractor
/tmp/.reports
// iMessage exploit artifacts (FORCEDENTRY / FINDMYPWN)
~/Library/SMS/Attachments/.com.apple.sms.plist
// Windows — Candiru / DevilsTongue
C:\ProgramData\Microsoft\DeviceSync\
C:\Users\Public\Downloads\.cache\
The algorithm is simple but effective: for each known artifact path, check if the file or directory exists. If it does, emit a ThreatIndicator with the appropriate severity and spyware name.
Process Enumeration
Threat Shield enumerates running processes and checks against known spyware process names:
// Algorithm (pseudocode)
processes = exec("ps aux") // or tasklist on Windows
for each process in processes:
for each known_signature in SPYWARE_PROCESSES:
if process.name matches known_signature:
emit ThreatIndicator(
category: "known_spyware",
severity: known_signature.severity,
spywareName: known_signature.name
)
Debugger & Instrumentation Detection
Spyware often attaches debuggers or instrumentation frameworks (Frida, Xposed) to intercept function calls. Threat Shield checks for:
// Check for active debugger
if (process.env.ELECTRON_IS_DEBUGGER) → suspicious
// Check for Frida (dynamic instrumentation)
scan for "frida-server" in process list
scan for frida-agent.dylib in loaded libraries
// Check for root/jailbreak indicators
exists("/Applications/Cydia.app")
exists("/usr/sbin/sshd") on mobile
writable("/private/") → jailbreak indicator
3. Layer 2: Behavioral & Network Monitoring
Advanced spyware like Pegasus may not leave static file artifacts (especially zero-click exploits that operate entirely in memory). Layer 2 detects anomalous runtime behavior and network connections that indicate active surveillance. These checks run every 15 minutes in the background.
C2 Network Connection Monitoring
Spyware communicates with Command & Control (C2) servers to exfiltrate data. Threat Shield checks active network connections against known C2 infrastructure from public threat intelligence:
// Check active connections against known C2 IPs
connections = exec("netstat -an | grep ESTABLISHED")
for each prefix in KNOWN_C2_IP_PREFIXES:
if connections.includes(prefix):
emit ThreatIndicator(severity: "high")
// Also check against known C2 domains
host_connections = exec("lsof -i -nP | grep ESTABLISHED")
for each domain in KNOWN_C2_DOMAINS:
if host_connections matches domain pattern:
emit ThreatIndicator(severity: "high")
Sources: Amnesty International, Citizen Lab, and open threat intelligence feeds. Includes known NSO Group infrastructure, Cytrox/Intellexa domains, and documented Pegasus CDN fronts.
CPU Usage Anomaly Detection
Spyware performing data exfiltration, audio/video capture, or keylogging consumes measurable CPU. Threat Shield establishes a baseline and flags significant deviations between scan intervals:
// CPU delta detection between 15-minute scans
cpu_usage = process.cpuUsage()
total_cpu = (cpu_usage.user + cpu_usage.system) / 1e6 // seconds
if baseline exists:
delta = total_cpu - baseline
if delta > 60: // 60+ CPU-seconds between scans
emit ThreatIndicator(severity: "low")
baseline = total_cpu
This catches background exfiltration that Pegasus performs in bursts. A single CPU anomaly emits a low-severity indicator — it takes corroborating static evidence to escalate beyond SUSPICIOUS.
Suspicious Port Detection
Certain listening ports indicate active instrumentation or proxy interception:
// Ports checked
27042, 27043 // Frida default ports → critical
1080 // SOCKS proxy → medium
8080, 8888, 9090 // Common proxy/debug ports → low
Library Injection Detection
On macOS, spyware injects dynamic libraries into running processes. Threat Shield checks for known injection mechanisms and suspicious loaded libraries:
// macOS: Check for injected libraries
if DYLD_INSERT_LIBRARIES is set → critical
if LD_PRELOAD is set → critical
loaded_libs = exec("vmmap PID | grep .dylib")
suspicious_patterns = ["frida", "substrate", "cycript", "inject", "hook", "spy"]
for each lib in loaded_libs:
if lib matches any suspicious_pattern:
emit ThreatIndicator(severity: "high")
4. Threat Scoring
Individual indicators are aggregated into a composite threat level using severity classification. This prevents false positives from a single low-confidence indicator while ensuring high-severity findings trigger immediate action.
Severity Classification
| Severity | Example |
|---|---|
| Critical | Pegasus staging directory found, Frida ports open, DYLD injection |
| High | C2 IP/domain match, MitM proxy certificate, debugger attached |
| Medium | System proxy active, SOCKS port listening, excess certificates |
| Low | CPU usage anomaly, common proxy/debug port open |
Escalation Logic
// Threat Level determination
if any indicator.severity == "critical":
level = CONFIRMED
else if count(severity == "high") >= 2:
level = CONFIRMED
else if has_static_evidence AND (has_high OR medium_count >= 3):
level = PROBABLE
else if has_high OR medium_count >= 3:
level = SUSPICIOUS // capped without static corroboration
else if medium_count > 0 OR has_low:
level = SUSPICIOUS
else:
level = CLEAR
False Positive Mitigation
Correlation requirement: Behavioral indicators (Layer 2) alone cannot escalate beyond SUSPICIOUS. At least one static (Layer 1) indicator must be present to reach PROBABLE. This means a coincidental CPU spike or a developer running Charles Proxy will not lock you out of the app.
Critical severity bypass: Critical findings (Pegasus file artifacts, Frida injection, DYLD library hijacking) immediately escalate to CONFIRMED regardless of source, because these are unambiguous indicators of compromise.
5. Automated Response
The engine is designed to take automatic protective action scaled to the threat level. What each level would do — and, where the page previously overstated it, what it actually does:
Normal operation. No indicators found.
Warning banner shown. User is advised to investigate. The app continues to function, and medium- and low-severity findings can be dismissed. The next scheduled scan is the ordinary 15-minute one.
Software updates are refused, so the update channel cannot be used against a compromised device. Messaging is not restricted — a reduced-send mode is planned and not implemented. Run a full device scan with external forensic tools.
LOCKDOWN: private keys are erased from local storage, the encrypted secure store is overwritten and deleted, the session is signed out, and updates are refused. Your account, contacts, and community memberships survive on the server. Local message history does not — see the Recovery Flow below.
6. Lockdown Recovery Flow
A CONFIRMED lockdown is a serious event — it means Railgun believes the device is compromised and has taken protective action. It is designed as a controlled emergency procedure, not a self-destruct, but it is not lossless either. Here is exactly what happens and how you recover.
What Gets Wiped
• Private encryption keys for the current device are securely erased from local storage.
• Decrypted message cache in memory is purged immediately.
• The encrypted secure store — session tokens and stored credentials — is overwritten with zeroes, deleted, and the session is signed out on that device.
• Local message history, which is the only copy there is. Railgun keeps no server-side archive, so a lockdown loses the conversations stored on that device.
What Is NOT Lost
• Your account — username, identity, and contacts remain on the server.
• Undelivered messages — envelopes still queued for you on the relay, up to their 30-day TTL, arrive on the new device. Anything already delivered and stored locally does not: there is no server-side history to restore from.
• Community memberships, roles, and permissions.
• Recovery codes — these are generated at registration and should be stored offline. They are your path back in.
How to Recover on a Clean Device
Secure a clean device. Factory reset the compromised device, or use a different device entirely. Consider professional forensic analysis of the compromised hardware.
Install Railgun on the clean device.
Log in with your recovery code. This re-authenticates your identity and generates a fresh key pair on the clean device, whose public half is published for others to encrypt to.
Contacts pick up the new key automatically for subsequent messages. Note the limit honestly: because the shipping client uses sealed boxes rather than a ratchet, messages sent to your old key before the wipe would still be readable by anyone who had extracted that key. Rotating is a recovery step, not retroactive protection.
Rotate your recovery codes from the new device as a precaution.
Do You Need a Second Trusted Device?
No. Recovery codes are the single recovery mechanism and are designed to work from any new device. However, if you have Railgun active on a second device, it can serve as an additional verification channel to confirm your identity during re-setup.
7. Known Spyware Signatures
The indicator set is a fixed list compiled from public research and shipped with the app. It is not a live feed and does not update between releases. Coverage is uneven, and the table below says which family is covered by what:
| Spyware | Vendor | Detection Method |
|---|---|---|
| Pegasus | NSO Group (Israel) | File artifacts, LaunchAgent persistence, iMessage exploit traces, C2 domains |
| Predator | Cytrox / Intellexa | C2 domain and IP patterns only — no file or process indicators are shipped for Predator |
| FinSpy | FinFisher (Germany) | File artifacts on macOS, Linux, and Windows. No binary hashing is performed |
| DevilsTongue | Candiru (Israel) | A small number of Windows staging paths. No registry inspection is implemented |
| Stalkerware | Various commercial | Process-name matching against known products (mSpy, FlexiSPY, Cocospy and others), filtered to entries applicable to the current desktop OS |
The indicator set was compiled from public sources including Amnesty International MVT, Citizen Lab, and MITRE ATT&CK. It was last revised in March 2026. Refreshing it requires a new release of the app.
8. Operational Status
Security credibility requires transparency. Here are the boring, operational details that let you verify Threat Shield is maintained and current.
| Enabled in shipping client | No — the engine is never started by the desktop app |
| IOC Set Last Revised | 2026-03-01 |
| IOC Sources | Amnesty MVT, Citizen Lab, MITRE ATT&CK, published threat research. Compiled by hand, shipped in the app, not fetched at runtime |
| Static Checks | 8 on macOS and Linux; 7 on Windows, where library-injection detection is skipped |
| Behavioral Checks | 3 checks (C2 network connections, CPU anomaly, suspicious ports) |
| Last Code Review | March 2026, internal. No independent security audit has been performed |
Platform Coverage
| Platform | Static (L1) | Behavioral (L2) |
|---|---|---|
| macOS (arm64, x64) | Full — 8 checks | Full — 3 checks |
| Windows (x64) | Partial — 7 checks | Partial |
| Linux (x64) | Partial | Full — 3 checks |
Windows: the library-injection check does not run at all, and the certificate-store and proxy checks have macOS-only implementations that return nothing. Behavioral C2 detection matches IP prefixes via netstat, but the domain-based check is macOS/Linux only.
Linux: all eight static checks execute, but the certificate-store and proxy checks are macOS-only internally and yield no findings. Process enumeration, injection environment variables, and all three behavioral checks are supported.
Every figure here describes the engine when it runs. It does not run in the current release.
False Positive Policy
Some indicators — debuggers, custom certificates, proxies like Charles, enterprise MDM agents — are legitimate in developer and corporate environments. Threat Shield handles this in three ways:
• Correlation requirement: Behavioral indicators (Layer 2) alone cannot escalate beyond SUSPICIOUS. A false-positive CPU spike or developer proxy will not lock you out.
• User override: medium- and low-severity indicators can be allowlisted and suppressed; high and critical ones never can. A SUSPICIOUS warning does not block app usage. PROBABLE blocks software updates, CONFIRMED triggers the key wipe, and both require corroborating static evidence.
• Critical bypass: Only unambiguous indicators (Pegasus artifacts, Frida injection, library hijacking) can directly reach CONFIRMED. These have near-zero false positive rates.
9. Privacy Guarantees
Threat Shield was designed with the same privacy-first principles as the rest of Railgun:
All detection is designed to run locally. No code path sends scan results, file hashes, process lists, or network logs to a server.
Threat Shield emits no telemetry, analytics, or crash reports of its own.
Findings are written to the local application log, which stays on your machine. If you send us a log for support, indicator descriptions will be in it.
Threat reports are held only in memory and are gone when the app restarts.
No independent audit of this code has been performed, and the client repository is not currently public — so this section is a disclosure, not something you can verify yourself today.
The short version
Threat Shield is a real piece of engineering that is not yet doing anything for you. Wiring it into the desktop app is the outstanding work; until that ships, this page is a description of intent. We would rather publish it in that state, labelled, than quietly imply you are being watched over.