Storage Was the Blind Spot. Now It’s Watching Back.

Storage arrays have long been one of the most targeted, yet least monitored, layers in the enterprise. The evidence is not theoretical. DarkSide spent nine days inside the network of a fuel pipeline operator before deploying ransomware, killing backup services and deleting shadow copies to ensure there was nothing left to recover without paying. Senate testimony from UnitedHealth’s CEO revealed that a similar nine-day gap in detection preceded what regulators now confirm as the largest healthcare data breach in US history. And an Ontario medical clinic had its backup repositories deleted during an attack — and because its access logs ran out of storage and were overwritten mid-attack, investigators lost the ability to reconstruct the earliest stages of the intrusion.

In each case, attackers had days of unmonitored access before the damage was done. At the fuel pipeline operator and the Ontario clinic, that access was used to disable backup infrastructure and delete recovery points — in the Ontario case, costing investigators part of the evidence trail along with it. In all three attacks, the same failure made the difference: no security tool was watching the storage and backup layer, and no automated response was waiting.

The Everpure and CrowdStrike integration changes that. This integration enables real-time detection and automated response when administrative commands that control Everpure™ FlashArray™ and FlashBlade^® are misused, triggering recovery actions directly within the SOC’s Falcon console.

What Everpure + CrowdStrike Deliver

Storage has historically been treated as a passive component of cybersecurity and recovery, lacking the native capabilities needed to flag suspicious administrative commands. Organizations now recognize that storage systems must monitor their control plane and deliver built-in detection capabilities to address the challenges posed by AI-driven threats. The Everpure and CrowdStrike integration turns storage into an active defender and strengthens the organization’s security posture through four concrete capabilities:

• Purity-native detections in your Falcon console: Nine validated, MITRE ATT&CK-mapped rules cover the most destructive threat-actor commands—firing in real time inside your existing CrowdStrike tenant, not a separate product or dashboard.
• Passthrough detection—no correlation delay: Traditional SIEM detections often wait for multiple related events before raising an alert. Passthrough detections trigger immediately when a high-risk storage command is observed—eliminating correlation delays for destructive operations such as snapshot deletion and eradication bypass.
• Automated SOAR response in seconds: CrowdStrike Fusion SOAR calls the FlashArray REST API directly and creates a new SafeMode™ Snapshot before a human has even finished reading the alert.
• Coverage for the step before the damage: DNS changes, NTP tampering, and syslog redirection—the defense-evasion moves adversaries make before a destructive payload executes—are also detected and surfaced to the SOC.

A Common Pattern in Major Ransomware Attacks

Look closely at how modern ransomware attacks unfold, and one step appears again and again—across energy, healthcare, government, and finance—with striking consistency: destroy the backups before encrypting the live data. It’s deliberate, because recovery data is the one thing that lets a victim walk away without paying. And in many of the most damaging incidents of the last five years, the attackers did not rush. They took their time.

These incidents reveal a consistent adversary playbook rather than isolated events. Across industries and ransomware families, adversaries first establish persistence, then disable recovery mechanisms, and finally execute the destructive payload. These incidents highlight the importance of detecting attacker activity during the preparation phase, before destructive actions compromise recovery mechanisms.

_{Note about these examples:
These incidents are presented as publicly documented examples and are not customer deployments of the Everpure + CrowdStrike integration. They illustrate a broader, well-documented adversary behavior: targeting recovery mechanisms and audit evidence before or during a destructive attack—not a claim that Everpure was involved in these incidents. Everpure SafeMode provides an additional layer of protection for recovery points by preventing modification or deletion during the configured retention period, subject to the applicable SafeMode controls and authorization model.}

That is the problem real-time monitoring is built to solve. Not better forensics after the fact, but rather a way to catch the destructive command the moment it’s issued by detecting the reconnaissance moves that precede it, while there is still time to act.

The Nine Detections: MITRE Att&ck-Mapped and Validated

The Everpure and CrowdStrike integration provides nine validated detection rules. Each detection was built against a specific Purity command, validated in testing, and mapped to the MITRE ATT&CK framework—the industry’s shared language for adversary behavior. This is not a generic pattern set. These rules focus on high-risk administrative commands that can indicate malicious or unauthorized activity.

These nine detections are published, not proprietary—and you are not limited to them

Every technique and tactic in the table above—T1490, T1485, T1562, T1562.006—is pulled directly from the publicly maintained MITRE ATT&CK Enterprise Matrix, the same framework your SOC already uses to triage every other Falcon alert. Nothing here is a proprietary label you have to learn or take on faith; look up any rule.id above against MITRE’s own site and the technique definition matches.

These nine detections are simply what ships pre-validated out of the box. Because they run as standard custom rules inside CrowdStrike NG-SIEM against the same Purity audit event stream, any customer can write additional passthrough or correlation rules against their own Purity commands and map them to whichever ATT&CK technique fits—without waiting on a vendor release.

MITRE ATT&CK-mapped, and extensible

The detections use MITRE ATT&CK techniques to provide standardized context for SOC investigation. The pre-validated rules can also be extended with additional custom rules based on customer requirements.
Two MITRE techniques dominate this library, and the distinction between them is important: T1490 (Inhibit System Recovery) is about destroying the ability to recover—snapshot deletion, PG deletion, eradication bypass. T1485 (Data Destruction) is about destroying the data itself—volume destruction, filesystem destruction, S3 bucket destroy. An adversary that has already compromised the backup software will typically execute T1490 first, then T1485 when ready for the final payload. The defense-evasion techniques (T1562, T1562.006) typically precede both.

Built for Real-time Detection and Response

Visibility into storage logs already existed before this integration—syslog forwarding could send Purity events to a SIEM, and an analyst could search them. Every one of the three case studies above shows exactly why that is not enough: the relevant log event almost certainly existed somewhere in each case. It was not caught when it mattered, because nothing was watching for it in real time and nothing was set up to act on it automatically. 

Two design decisions make the difference.

First, detection has to happen at ingest, not on a delay. A correlation engine that waits to accumulate a pattern of events is the right tool for subtle signals, but it’s the wrong tool for dangerous commands like a snapshot deletion—by the time the pattern forms, the recovery point is gone. So the seven most critical storage events are designated Passthrough tier: They carry event.severity=80 and a named rule.id the instant they’re parsed, and they skip the correlation engine entirely.

Second, detection had to trigger action, not just an alert. An analyst receiving a notification at 2am is still losing the race against an adversary that is already moving to the next step. So the same detection that fires the alert also triggers a CrowdStrike Fusion SOAR workflow that calls the Purity REST API directly and rebuilds the recovery point—before a human has opened the notification.

How it works, end to end

The architecture below shows what happens from the moment a destructive command executes on FlashArray or FlashBlade to the moment a clean recovery point is re-established.

What this Looks Like in Practice—Two Real Sequences

Here’s the actual data flowing through each of the two main detection scenarios: raw syslog, parsed fields, and what the SOC sees. These are not synthetic examples. These are real audit events from a production array.

Scenario 1: Protection group snapshot destroyed  (T1490 – Passthrough – CRITICAL)

MITRE context: T1490—Inhibit System Recovery. Adversaries delete volume shadow copies, backup repositories, and snapshots to ensure the victim cannot recover without paying. DarkSide used exactly this technique in a well-documented 2021 attack on a major fuel pipeline operator. On a Purity array, purepgroup destroy targeting a .snapshot object is the array-layer equivalent of vssadmin delete shadows on a Windows host.

Raw event arriving at the connector:

After NG-SIEM parsing—structured and queryable:

event.severity: 80 triggers Passthrough—no correlation window, no delay. CrowdStrike Fusion SOAR fires immediately and does three things: 

• Calls the FlashArray REST API and creates a new SafeMode snapshot of the same protection group
• Sends a P1 notification to the SOC with the array name, protection group, initiating account, Message ID, and MITRE technique
• Writes the full sequence back into NG-SIEM as an auditable record. 

End-to-end, the automated response occurs in seconds.

Scenario 2: Syslog gets redirected mid-session (T1562.006 – Passthrough – HIGH)

MITRE context: T1562.006 — Indicator Blocking. Adversaries modify audit and authentication logging to evade detection. Redirecting syslog output to an adversary-controlled host suppresses the evidence trail immediately before a destructive payload—the same defense-evasion pattern seen in real-world ransomware intrusions, executed at the storage layer.

Raw event:

This fires as passthrough rather than correlation because syslog redirection to an unfamiliar destination is treated as individually sufficient for a detection—the SOC needs to know the moment it happens, not after a pattern accumulates. The SOC sees the redirection attempt before whatever it was meant to hide has a chance to execute.

Outcome: Accelerate detection and response

• Detection tuned to the attack: Purity audit activity is monitored continuously, catching defense-evasion moves like DNS and syslog tampering before the destructive payload lands—not just after.
• Automated response in seconds: The moment a critical event fires—snapshot deletion, volume destruction, eradication bypass—Fusion SOAR responds automatically, with full context (array, command, user, MITRE technique) in every alert.
• Continuous monitoring: A complete automatic audit trail—detection, SOAR action, and outcome written back into NG-SIEM the moment the response completes, which matters later when you’re reconstructing exactly what happened for a regulator, an auditor, or your own leadership.
• Detect, investigate, and respond from a single Falcon console: Detection that fires inside your own CrowdStrike Falcon tenant—not delegated to a third-party SOC queue. Your team sees it first, owns the investigation, and watches the automated action execute in your own console.

Closing Thoughts

The hardest part of defending storage has never been the evidence. In every incident above, the logs existed. The commands fired. The timestamps were there — overwritten in one case, reconstructed in another, testified about before Congress in the third. The problem was never visibility. It was speed: no detection in real time, no response executing automatically, no recovery point being rebuilt while the attacker was still in the environment.

That is what this integration changes. Not a new console to learn, not a new workflow to build — nine named, MITRE ATT&CK-mapped detection rules running inside the Falcon tenant your SOC is already in, with automated recovery executing before the analyst finishes reading the alert.

Storage was the blind spot. Now it’s watching back.

Want to see this running against your own environment? Reach out to your CrowdStrike or Everpure account team to discuss enabling passthrough detection and CrowdStrike Fusion SOAR playbooks for FlashArray and FlashBlade.