What NeuraWall detects without decrypting.
NeuraWall never decrypts traffic and never stores payloads. It works from flow metadata, so what it can find depends on what the sensor can see.
Visible in encrypted traffic
| Signal | Used by | What it can find |
|---|---|---|
| Flow shape: bytes in and out, packet counts, durations, timing | Tier 1 anomaly engine (Isolation Forest, EWMA baselines) | A host that suddenly behaves differently, scans, floods |
| Inter-arrival timing of one flow | Beacon detector | Regular call-backs to a server (C2 beaconing) |
| Volume and direction | Exfiltration detector | Very large outbound transfers (20 MB and up) |
| TLS handshake: SNI, TLS version, JA3 / JA4, ALPN | TLS mismatch detector | A client claiming to be a browser with a non-browser fingerprint |
| DNS query names | DNS detector | DGA-looking names and DNS tunnelling |
Needs the request visible
| Needs the request visible (plain HTTP, or a sensor behind your TLS terminator) | Used by |
|---|---|
| HTTP path and query | Injection detector: SQL, command and template injection, path traversal, XSS |
The honest limit
On a public HTTPS service the injection detector sees nothing unless the sensor sits behind the TLS terminator, or you already run sensor-side decryption. Tier 1 and the signals in the first table work either way.
The detectors are heuristics with known gaps, and we publish them: see the Tier 2 evasion report. A detector can only raise an alert; a person approves any rule that blocks.