Linux alert volume grows faster than security teams do. Sandfly 6.0 analyzes your hosts in the background, groups what it finds by artifact, and prioritizes it so your team opens the dashboard to a ranked list of real problems instead of a backlog of maybes. It does this agentlessly, with no software installed on your hosts, and it works with or without AI in the loop.
Sandfly is an agentless Linux security platform: it finds intrusions, malware and implants on Linux hosts without installing any software on them, making it an agentless alternative to traditional Linux EDR.
If you run any reasonably sized Linux system, you already know the pattern. Your tools light up every time a signature fires, every anomalous process spawns, every container drifts from a baseline. Analysts click into isolated alerts, try to reconstruct what is actually happening on a host, and then repeat the exercise across dozens of nearly identical events.
On Linux, this is worse. Network implants, backdoors, fileless loaders, and stealthy crypto miners often avoid logs entirely. You end up with a paradox: too many alerts, but not enough real forensic evidence to decide which ones matter. Sandfly 6.0 is built to treat this as a data and workflow problem, not something another dashboard can fix.
See everything new in Sandfly 6.0 ->
The first shift in Sandfly 6.0 is conceptual. Instead of treating every detection as a standalone alert, we group everything around a single forensic artifact, a process, file, or user that represents the thing you actually care about investigating.
In the old model, a single compromised process might generate five or ten separate alerts. You had to click into each one, keep the details in your head, and mentally stitch them together into a coherent story. In Sandfly 6.0, that same situation becomes one artifact representing the suspicious process, with all detections stacked underneath it.
Open the artifact and you immediately see:
We surface fleet context directly inside the artifact. If a suspicious process has only ever appeared on one host, that is a very different signal from something seen on 3,982 systems. You get an immediate sense of whether you are dealing with an outlier or just a noisy but benign pattern.
The result is simple but powerful: analysts work the evidence, not an alert queue. You triage one record per suspicious process, file, or user, with the relevant detections, live state, and fleet-wide context already assembled.
Sandfly 6.0 includes a machine-learning malware classifier built specifically to hunt for Linux network implants. We trained it on tens of thousands of malware samples from our own research library and public sources, focused on the threats that actually matter on Linux: passive backdoors, magic-packet implants, tiny binaries waiting for command and control, fileless loaders, and stealthy bots and proxies. These are the tactics used by nation state attackers against critical infrastructure globally.
Like the rest of Sandfly, the classifier runs agentlessly on the remote host, with nothing installed. We are not shipping binaries back to a central service for analysis; we perform fast static analysis in place even in air-gapped environments and completely privately.
That extra analysis sits on top of a faster scanning engine. Sandfly 6.0 includes significant performance optimizations to how scans run, so the overall impact on the systems you are scanning is lower than before even with advanced network implant detection present.
The implant detection works across every platform we support such as: Intel and AMD servers, ARM and MIPS devices, IBM Power, and IBM S390 mainframes. The goal is straightforward: if Sandfly supports the platform, the implant classifier should work there too.Whether it’s a cloud server or tiny embedded device, they all get identical coverage against advanced threats.
The classifier scores threat level and advanced tags to provide visibility into what a binary is capable of doing. Scoring and tagging now includes:
These tags give both humans and downstream automation enough context to understand why a binary is suspicious. In one recent test with a telco-targeting implant we had never seen during training, the classifier still scored it at 98–99 out of 100 and correctly categorized it as a high-risk backdoor, with all the suspicious behaviors spelled out in the artifact view.
In addition, Sandfly can be used to scan and identify compromised systems that may be running network implants today or have evidence of implants left behind on disk. Systems that have never had any security applied to them can get a rapid and accurate check if any problems exist instantly.
AI is optional in Sandfly 6.0. The artifact view, severity scoring, implant classifier and whitelisting all work without it. For teams that do want it, the third major change is how we integrate large language models into the investigation flow. We are not asking you to dump unfiltered logs into an LLM and hope for the best. Instead, we feed models the same structured forensic artifacts that analysts see, enriched with implant classifier scores and tags.
Sandfly 6.0 separates AI usage into two distinct layers:
Fast triage: a lighter, cheaper model that reviews new artifacts, uses Sandfly’s evidence to decide whether to escalate or downgrade, and updates severity before analysts ever log in.
Deep analysis: a more capable model that, when requested, performs a full forensic write-up on a specific artifact using the detailed tags, decoded strings, live network state, and indicators of compromise Sandfly has already extracted.
This architecture lines up well with independent research. LLMs struggle to separate real attacks from false positives when given raw IDS alerts alone, but become significantly more effective when alerts are enriched with system context and carefully chosen examples (Schärmer et al., AIT). Research on agentic alert investigation points the same way: the CORTEX framework, which grounds each decision in evidence gathered through specific, structured tools, substantially reduced false positives compared with single models that interpret noisy logs end-to-end (Wei et al., arXiv).
Operationally, you are not locked into a single AI vendor. Sandfly 6.0 works with commercial frontier models and on‑prem deployments through an OpenAI-compatible API. If you already have an internal model approved for sensitive environments, you configure it once and Sandfly takes care of passing structured evidence, not raw host state, to that endpoint.
For customers in high-sensitivity environments, the key point is control. You decide whether to enable AI triage at all, which model to use, and whether that model lives on your own infrastructure. Sandfly’s role is to produce clean, high-fidelity data that makes those models useful.
Even a well-tuned detection engine will encounter organization-specific noise: custom daemons, legacy scripts, odd backup tools that look suspicious on paper but are standard operating procedure on your network. Sandfly 6.0 makes it much faster to eliminate that noise without missing what matters.
The bulk whitelisting workflow is built directly on top of the forensic artifact and fleet-context view. When you see an artifact that shows up across thousands of hosts and you know it is benign, you can:
If you had 5,000 alerts tied to one known-good artifact, they disappear immediately once you approve the whitelist. You do not have to go back and clean out historical alerts by hand. During initial deployment, this takes a large share of the tuning work and noise off your analysts.
Because we show you exactly how many hosts have seen a given artifact, you are less likely to accidentally whitelist a one-off suspicious process. A process seen on 3,982 systems is a very different candidate from something that has only ever executed on one host at 3 a.m. local time.
What Sandfly 6.0 changes in your day-to-day workflow
The net effect of Sandfly 6.0 is not just a list of new features; it is a different way of doing Linux incident response. Analysts start their day in the host triage view, where Sandfly, and your chosen AI model if you use one, has already pushed likely compromises to the top and downgraded noisy defaults.
Instead of dozens of fragmented alerts, you open a handful of high-priority forensic artifacts. For each one, you see live network state, decoded strings, classifier scores, behavioral tags, and host count in a single screen. If something looks serious and you have AI enabled, you can kick off a deep AI analysis and get a structured explanation that is grounded in real evidence, not guesses.
Tuning becomes a periodic, targeted task instead of a constant drain. When you see artifacts that are obviously benign and widely deployed, you bulk whitelist them and wipe out thousands of low-value alerts at once. When you encounter something novel, a static implant dropped into an unexpected directory, an odd fileless loader, a masquerading kernel thread, Sandfly’s implant classifier and artifact view give you enough detail to make a confident decision quickly.
Most importantly, you are no longer trying to make sense of Linux attacks from logs alone. Sandfly 6.0 collects, analyzes, and structures the underlying forensic evidence for you, then gives both humans and AI the same clean, high-fidelity view. In hostile environments, that is the difference between chasing alerts and actually understanding what is running on your systems.