A legacy threat, undetected for seven years

During a routine EDR onboarding, Huntress identified an active ransomware persistence mechanism on a client server within hours of agent installation. The artifact, a Dharma ransomware indicator in the local user Startup folder, was not new. Files recovered from the host confirm it was tied to a completed ransomware encryption event on September 24, 2018, nearly eight years before Huntress caught it, and years before either EDR product discussed here was installed on the host.

What matters for this comparison is not who was present in 2018. Neither was. It is what happened when each product later encountered the same remnants on the same disk.

SentinelOne was installed on this host in May 2025. With real-time protection enabled in Protect and Kill & Quarantine mode, and both static and behavioral detection engines active, it completed a full disk scan the day after installation. Despite the host carrying a known ransomware persistence artifact and its encrypted remnants, SentinelOne found nothing to flag and generated no detection, suppression, or logged event of any kind across more than a year of coverage. Huntress, installed on the same host over a year later with no historical context to draw on, identified and acted on the same artifact within hours.

This case study documents the investigation that ruled out the ordinary explanations for SentinelOne's miss: misconfiguration, scan-cadence gaps, and file exclusions, and what was left once each was eliminated.

Tailored Technology Services manages endpoint security for a manufacturing client using a combination of SentinelOne, in place since 2025, and Huntress, which was being layered in as part of an EDR consolidation project already underway across the client's environment.

As part of that onboarding, Huntress flagged a Critical incident on an application server within hours of its agent going live. The investigative summary identified the artifact as consistent with Dharma ransomware persistence, created years before SentinelOne was installed on the host, and recommended reviewing the system for signs of live compromise. TTS's own review of files remaining on disk confirmed this was tied to a completed encryption event from September 2018.

A malicious startup-folder entry named to mimic a Windows system file, using a naming pattern consistent with known Dharma ransomware variants.

A creation timestamp of September 24, 2018, roughly six and a half years before SentinelOne was installed on the host.

A small set of encrypted files elsewhere on disk, all timestamped to the same minute as the persistence artifact and carrying the same attacker ID and contact email. That confirmed a completed encryption event, not just staged persistence. Only a handful of files were affected before the attack stopped, years before any EDR product discussed here was present on this host.

Huntress classified the incident Critical, automatically isolated the host from the network, and staged assisted remediation: delete the file, then reboot to complete cleanup.

Huntress's own writeup noted the host was newly enrolled with them and flagged that telemetry prior to enrollment was necessarily limited. That cautious note prompted TTS to independently verify SentinelOne's coverage rather than accept the finding at face value.

A single missed detection is not automatically a meaningful data point. Most misses turn out to have a mundane explanation: an agent that was never installed, a scan that never ran, a policy set to Detect-only, or an exclusion rule quietly carving out the exact file in question. TTS worked through each of these possibilities using SentinelOne's own console data.

Was the agent actually protecting this host? The host's agent record showed a clean install and registration, an up-to-date agent version, and active EDR coverage with no pending uninstall, no disabled state, and no reported infection. That ruled out "the agent was not really running."

Was protection mode set to block, or just watch? The policy governing this host had Malicious Threats set to Protect with Kill & Quarantine as the enforcement action, not Detect-only. Both Static AI and Behavioral AI detection engines were enabled, along with Reputation, Lateral Movement, Anti-Exploitation/Fileless, and Potentially Unwanted Application detection. Only two engines were off, and both were irrelevant to this scenario (container-only features). That ruled out a passive or watch-only configuration.

Did a scan ever actually touch this file? Agent telemetry confirmed a full disk scan completed the day after the agent was installed, well after the malicious file had been sitting on disk for years. A scan that never ran would have been the simplest explanation for a miss. That possibility was eliminated.

Was the file or its location excluded from scanning? TTS pulled the account's complete exclusion list: 221 entries covering known-good hashes and a small number of application-compatibility path exclusions. None of the path exclusions covered the user Startup folder or anything resembling it, and none of the 221 hash exclusions matched the malicious file's hash. That ruled out an exclusion rule.

Did the platform log the file anywhere, even a clean result? A search of the platform's event history, by file hash and independently by filename pattern, across the full period of agent coverage returned no matching events of any kind. Not a detection, not a suppressed alert, not a benign classification. Combined with the confirmed full disk scan, this indicates the file was never flagged, at any severity, at any point after the agent went live.

With every ordinary explanation checked and eliminated, the finding stands on its own: a fully licensed, fully enabled, actively protecting SentinelOne agent completed a full scan of a host carrying both a live, publicly known ransomware persistence artifact and a set of files encrypted in a real 2018 attack, and never logged so much as a clean scan result for any of it. The file was not excluded, the engine was not disabled, and the scan was not skipped.

Huntress, by contrast, identified and acted on the same artifact within hours of being installed on the same host, with no prior telemetry and no historical context to draw on.

Neither SentinelOne nor Huntress existed on this host in 2018, and neither can be credited or faulted for the original attack. The comparison here is about what happened when each product later encountered the same remnants: one ran a full scan and logged nothing, the other flagged it as Critical within hours of installation.

September 24, 2018: Dharma ransomware encrypts a small set of files on the host and plants a persistence mechanism in the user Startup folder. No EDR product discussed in this case study existed on the host yet.

May 2, 2025: SentinelOne agent installed and registered on the host, replacing an earlier security product, as part of the account's standard EDR deployment.

May 3, 2025: SentinelOne completed a full disk scan of the host. Scan reported clean. No threat generated, logged, or suppressed for the persistence file or the encrypted remnants.

August 20, 2026: Huntress, newly onboarded to the same host, identified the persistence artifact within hours of agent installation and flagged it Critical.

August 20, 2026: Huntress isolated the host automatically and issued assisted remediation (delete file and reboot).

August 20, 2026: TTS confirmed no exclusion, path rule, or policy setting explained SentinelOne's miss, then executed remediation: file deleted, host rebooted.

The malicious startup-folder file was deleted per Huntress's assisted remediation. The host was rebooted to complete cleanup and clear any pending persistence. The host was confirmed isolated during remediation and returned to normal network state afterward.

No indicators of active encryption, ongoing compromise, or lateral movement were identified during the investigation.

Static detection engines are a foundational layer of any EDR platform, but this case is a reminder that "fully licensed and enabled" is not the same as "catching everything." A well-documented ransomware family, complete with its own encrypted files still sitting on disk, sat through a complete scan on a properly configured agent without generating so much as a suppressed alert.

It also illustrates the value of layering platforms, or periodically re-scanning legacy hosts with a second engine, particularly for systems with a long history or an incident in their past that was never fully remediated. A clean scan result under one platform is not proof a host is actually clean, especially when nobody has gone back to check what is still sitting on disk from years earlier.

Treat a clean scan history as a starting hypothesis, not a conclusion, especially on hosts with a long history or any past incident that was never fully verified as resolved.

When retiring or replacing an EDR product, retain or export its historical logs before decommissioning, so future investigations are not left with an unverifiable gap.

Where feasible, run a second-opinion scan (a different engine or vendor) against legacy or newly acquired hosts as part of onboarding, rather than relying solely on one platform's own scan history.

When any EDR flags an incident on a newly enrolled host, resist the urge to dismiss it as "just catching up." Investigate whether the prior platform had a genuine opportunity to catch it, and document what you find.

Maintain a repeatable checklist for verifying a miss: agent health, protection mode, engine status, exclusion list, and full event history. Ruling explanations out systematically is what turns an anecdote into evidence.

This case study describes a real incident affecting a Tailored Technology Services client. Identifying details have been generalized to protect client confidentiality. Timelines reflect data from vendor incident reports and internal documentation.