Threat Hunting in the Rear-View Mirror: Why Backup Snapshots Are an Underused IoC Goldmine
There is a misconception in security operations that once you’ve lost endpoint visibility or trust in security tooling, you’ve lost the investigation. This is the norm now, with End-point Detection & Response now the norm and baked into Ransomware-as-a-Service Platforms.
That assumption breaks down the moment you realise something fundamental: attackers operate in time, but most security tooling operates in the present.
Your secret weapon: backups, snapshots give you time back. When you combine snapshots with Indicator of Compromise (IoC)–driven threat hunting, you move from reacting to what you can still see… to analysing what the attacker actually did.
What Is an Indicator of Compromise, and Why Does It Matter More Than Malware Signatures?
An Indicator of Compromise (IoC) is effectively forensic evidence that a system has already been breached. Normally digital artefacts such as file hashes, unusual login activity, registry changes or suspicious network connections.
They are best thought of as breadcrumbs left behind by the adversary. Traditional malware scanning is still largely a pattern-matching exercise (yes, yes: I know about behavioural analytics and heuristics), looking for bad hashes and bad signatures.
That worked when attacks were mainly malware-centric, but it breaks down in today’s world dominated by Identity compromise, Living-off-the-Land techniques and weaponisation of vulnerabilities so fast signatures haven’t been updated.
In these attacks there may be no malware to detect, or you don’t yet have a signature for the malware.
IoCs, on the other hand, operate at a different layer, looking for evidence of what happened, not just what executed or is lying in the filesystem.
Malware scanning tells you what shouldn’t be there, whereas IoC hunting tells you what shouldn’t have happened.
That becomes significantly more powerful when it can be applied to historical data, such as that which resides in backup snapshots.
Why Backup Snapshots Change the Game for IoC Hunting
Most security tooling is dependent on:
Agents being alive
Logs not being tampered with
Telemetry pipelines still functioning
Attackers know this, which is why nation-state and ransomware gang tradecraft routinely involves:
Disabling end-point security controls like EDR
Wiping logs
Disrupting telemetry
IoCs don’t just disappear, your ability to see them in real time does. Backup snapshots fundamentally alter that equation.
They give you:
Point-in-time system state (before, during, after compromise).
Untampered artefacts (especially when stored on an immutable backup platform).
A longitudinal view of attacker activity.
This provides a superpower most SOCs haven’t yet achieved: time-series IoC analysis. This means that instead of getting answers to “What can I see right now?”, you can get answers to the question “When did this first appear, how did it evolve and what changed alongside it?”
That superpower spends and reduces effort to identify:
Patient zero
Lateral movement paths
Staged persistence
Pre-positioning before detonation (common in wiper attacks)
In practical security operations, backup snapshots allow you to:
Diff file systems across time
Track registry or configuration drift
Identify when credentials or binaries first appeared
Validate whether remediation actually removed artefacts
This is not just detection, it is reconstruction. That is one of the reasons why, after two decades spent helping build some of the world’s largest security operations centres, I ended up at a backup vendor. Backup has a far bigger role to play than simply sitting with IT waiting for the recovery phase; used properly, it becomes valuable across a wide range of detection and investigative use cases long before restoration begins.
YARA: Detection as Code for Filesystem-Level Hunting
If IoCs are the breadcrumbs, YARA is the recipe that uses them. YARA provides one of the most effective ways to systematically search for IoCs at scale.
YARA allows analysts to define rules that match:
File contents (strings, byte patterns)
File structure
File metadata conditions
It is widely used as a form of “detection as code”, enabling repeatable identification of suspicious artefacts across large datasets.
In the context of backup snapshots, this becomes particularly powerful.
Why YARA Works Well on Snapshots
No dependency on runtime telemetry. You are scanning static data, not relying on live system behaviour.
Consistent execution environment. Snapshots eliminate variability caused by system state changes during analysis.
Historical sweep capability. The same rule can be applied across weeks, months or even years of snapshots; and multiple systems simultaneously
Detection beyond known malware. YARA rules can be written to detect:
Suspicious scripts
Embedded credentials
Configuration anomalies
Artefacts left by the use of tooling commonly used in Living-of-the-Land attacks
Most organisations use YARA in a look forward most:
YARA rules are downloaded
Real-time detection rules are updated, but the events have already occurred
A threat hunt takes place, but by this stage of the attack the EDR may have already been evaded, so good luck.
With backup snapshots, you can invert that model to apply today’s intelligence to yesterday’s data. This is critical as threat intelligence will always lag behind adversary behaviour. The ability to retrospectively detect the early stages of an attack using threat intelligence that has just come to light when your EDR has been evaded should be a capability every SOC should have. Many organisations threat hunt using their new threat intelligence blissfully ignorant that they’re hunting with a blindfold on.
This retrospective capability allows you to identify:
Missed detections
Dormant tooling
Early-stage compromise that predated alerting
The Dangerous Assumption: “No IoCs Means It’s Clean”
This is one of the most common, and most dangerous, conclusions in incident response. A snapshot with no observable IoCs is often treated as a safe recovery point. Once you understand adversary behaviour that assumption does not hold up under scrutiny.
There is often a material delay between initial access and observable artefacts.
Attack lifecycle reality:
Initial access (credential theft, exploit)
Quiet reconnaissance
Credential access and privilege escalation
Lateral movement
Persistence establishment
Impact (ransomware, wiper, exfiltration)
IoCs tend to appear later in the chain, this means:
Early snapshots may be compromised but clean-looking
Later snapshots show clear indicators
The actual breach occurred somewhere in between
This is well understood in threat intelligence, but unfortunately backup admins buying data management solutions with IoC scanning capabilities often don’t understand what this means:
IoCs are inherently reactive and post-compromise signals
Attackers can operate undetected for extended periods before evidence emerges
If you select a recovery point based purely on no malware detected or no IoCs present, you risk:
Reintroducing persistence
Restoring compromised identities
Bringing back attacker tooling
You are not recovering to a trusted state, you are just rewinding the attack to an earlier checkpoint.
A More Robust Approach: IoC-Informed Recovery
Using backup snapshots effectively requires shifting from binary thinking (“clean vs infected”) to probabilistic confidence. A more mature approach looks like:
Identify Known IoCs. These come from threat intelligence feeds (in the case of Cohesity, from Google Mandiant), incident report findings or YARA rules repositories.
Sweep Across Snapshot Timeline. Determine first appearance and spread across systems
Establish a “Confidence Window. Earliest known IoC-free point, plus buffer for dwell time uncertainty
Correlate with Behavioural Signals. Which is the step often skipped due to the misconception “no IoCs = clean snapshot)”. Look specifically for: authentication anomalies, privilege changes and configuration drift. These are all signals that can be found by using a backup solution for cold log access to time-series snapshot differential analysis.
This is where backup platforms stop being passive storage and become an evasion-resistant forensic dataset.
Traditional security tooling is designed to detect attacks as they happen, where as backup snapshots allow you to understand attacks as they actually unfolded. That distinction is subtle, but operationally critical.
If you rely solely on real-time detection you are constrained by what the attacker allows you to see, but if you incorporate IoC hunting across snapshots you are analysing what the attacker could not fully erase.
In today’s ransomware and wiper attacks built on identity abuse and legitimate tooling that difference is often the line between recovering fast and recovering safely.
