Filecatalyst: Detection

On the wire: TCP segments with payload size 24 or 32 bytes, repeating with millisecond precision. Normal background noise doesn’t do that. | Layer | Tool | What to look for | |-------|------|------------------| | Flow | ntopng, ElastiFlow | Asymmetric byte ratio >100:1 + constant packet gap | | Packet | tshark | tcp.payload_length == 24 and frame.time_delta between 5–15 sec | | IDS | Suricata | Custom rule matching TLS JA3S hash (ask me for the hash list) | | Logs | Zeek | ssl log with server_name containing unusual subdomains + cipher suite 0x1301 | Pro tip: FileCatalyst often coexists with Aspera or Signiant in media networks. Don’t confuse the two — Aspera uses FASP‑UDP with a different initial window and congestion signature. 4. Two Real‑World Detection Scenarios Scenario 1 – Unauthorized server in R&D Your NDR platform alerts on a workstation sending 800 Mbps to an unknown cloud IP on UDP/443. Standard inspection shows “QUIC” — but the packet size distribution doesn’t match QUIC. You pull a PCAP and see the 24‑byte control probe. It’s FileCatalyst Direct tunneling over port 443.

FileCatalyst can run on any port. Administrators routinely change ports to avoid conflicts, bypass firewalls, or even hide transfers. If your detection strategy is “look for port 33000,” you’re already missing the majority of traffic. filecatalyst detection

You can’t secure what you can’t see. So how do you detect FileCatalyst on your network — without false positives or drowning in packet captures? On the wire: TCP segments with payload size