Sandfly Security

What is it?

Sandfly is an agentless endpoint detection and response platform built exclusively for Linux. Instead of installing a persistent agent on each host, Sandfly connects to endpoints over SSH, deploys a temporary scanning binary, executes detection checks, retrieves the results, and removes the binary when finished. The scanning infrastructure consists of a central server that manages scheduling and stores results, and scanning nodes that poll the server for tasks, authenticate to target hosts using SSH keys or passwords, and execute scans.

The scanning engine is a compiled Go binary embedded inside the scanning node at build time. When a scan is triggered, the node establishes an SSH session to the target host, creates a randomly named temporary directory, transfers the scanner binary, and executes it. The scanner runs its analysis and returns structured results via stdout. After collection, the node deletes the binary and temporary directory from the target. An optional persistent mode skips cleanup to reduce overhead for frequently scanned hosts.

Sandfly supports Linux across x86_64, ARM, MIPS, and PowerPC architectures. This broad architecture support is significant because much of the Linux attack surface in critical infrastructure (telecommunications equipment, embedded systems, IoT devices, network appliances) runs on non-x86 hardware where traditional agent-based EDR either cannot deploy or is not certified for use.

Why did they build it?

Linux lacks the standardized detection and response frameworks that exist on Windows. There is no equivalent of ETW (Event Tracing for Windows), no AMSI, and no consistent kernel telemetry interface across distributions and versions. The Linux ecosystem is fragmented across distributions, kernel versions, init systems, and CPU architectures, making it difficult for traditional agent-based EDR vendors to maintain stable kernel modules across the full matrix of supported environments. Agent-based approaches on Linux frequently cause stability concerns in production, particularly on systems running custom or older kernels common in telecommunications and critical infrastructure.

The agentless approach sidesteps these problems entirely. Because Sandfly uses SSH as its transport and deploys a self-contained userspace binary, it does not require kernel modules, eBPF support, or distribution-specific packaging. It works on any Linux system with SSH access, regardless of kernel version or distribution. This also means the detection system itself is harder for attackers to tamper with, since there is no persistent process on the endpoint to kill or subvert.

The Salt Typhoon campaign highlighted this gap. Telecommunications providers with large Linux estates needed to assess their exposure quickly, but lacked tooling that could scan across heterogeneous Linux environments without deploying agents to each system.

How does it detect threats without persistent monitoring?

Sandfly uses point-in-time scanning rather than continuous behavioral monitoring. Each scan deploys the engine, which inspects the current state of the host’s filesystem, processes, users, network connections, loaded kernel modules, and system configuration. The scanner checks for indicators of compromise across thousands of detection modules covering rootkits, backdoors, process masquerading, crontab manipulation, unauthorized SSH keys, tampered binaries, and anomalous network listeners.

For unknown threat detection, Sandfly uses what it calls “drift detection,” comparing the observed state of a system against expected baselines. Rather than relying solely on signatures or known IOCs, it flags deviations such as unexpected SUID binaries, processes running from deleted executables, modified system binaries, or SSH authorized_keys entries that were not present in previous scans.

The scanner also performs process forensics by examining /proc entries for signs of evasion, such as processes with deleted executables, mismatched process names versus binary paths, processes with suspicious environment variables, and hidden or orphaned processes. On the filesystem side, it checks for timestamp manipulation, hidden directories, and files with anomalous attributes.

How does SSH key and credential auditing work?

Sandfly inventories SSH authorized_keys files across all user accounts on every scanned host, building a map of which keys grant access to which systems. This addresses a common blind spot: organizations frequently lose track of which SSH keys exist across their Linux fleet, creating unmonitored lateral movement paths. Sandfly detects unauthorized key additions, keys with overly permissive options (such as command restrictions being removed), and keys that appear on systems where they were not previously authorized.

The platform also tracks SSH credential usage patterns, identifying credential sharing across hosts and detecting potential stolen credential reuse. Because Sandfly scans across the entire fleet, it can correlate SSH key presence across all endpoints to build a comprehensive access graph.

Risky Business appearances

  • Snake Oilers 20 pt2 (Oct 2024), Craig Rowland pitches the agentless Linux security platform
  • RB #776 (Jan 2025), sponsored segment with Craig Rowland on Linux detection gaps and the Salt Typhoon context
  • Risky Business News newsletter sponsor (recurring)

Sources

Disclosure

Sandfly Security is a Risky Business sponsor.