How to detect data destruction attacks (T1485) with Log360

What is data destruction (T1485)?

T1485 (Data Destruction) describes adversary techniques for destroying data on target systems to disrupt availability. This includes overwriting files, corrupting file system structures, wiping disk sectors, and mass-deleting files or databases. The defining characteristic is irreversibility - unlike ransomware encryption (T1486), destroyed data cannot be recovered through any key or payment.

Wiper malware is frequently used in nation-state campaigns. HermeticWiper corrupted the master boot record and partition tables of Ukrainian government systems in February 2022. WhisperGate disguised itself as ransomware but overwrote data with no decryption mechanism. NotPetya caused an estimated $10 billion in damages globally, spreading through supply chain compromise and destroying data across multinational corporations.

These attacks share a consistent operational pattern: the adversary disables defensive services, deletes shadow copies and backups, then executes mass file destruction or disk-level wiping. Detection depends on catching any stage of this sequence before destruction completes.

Why T1485 matters to the SOC

Data destruction incidents differ from other impact techniques because the SOC cannot negotiate or pay its way out. With ransomware, there is at least the theoretical option of decryption through payment (though NIST SP 800-61r3 and law enforcement agencies discourage it). With a wiper, the data is gone. Recovery depends entirely on whether offline or immutable backups survived the attack.

The Verizon 2025 DBIR documented a significant increase in destructive attacks tied to geopolitical conflict. The Microsoft Digital Defense Report noted that wiper deployments increased 300% in countries adjacent to active conflict zones. These are operational realities that SOC teams face when defending organizations with geopolitical exposure, critical infrastructure classification, or supply chain relationships with targeted entities.

Detection speed directly affects outcomes for T1485. A wiper that runs for 30 seconds may destroy thousands of files. One that runs for 10 minutes can render an entire file server unrecoverable. The window between first detectable signal and irreversible damage is measured in seconds, not hours.

Built-in Log360 detection coverage

Log360 provides two built-in detection rules directly mapped to T1485 behavior. These form the foundation of data destruction detection on Windows endpoints.

Suspicious Bulk File Modifications or Deletions on Windows

The Suspicious Bulk File Modifications or Deletions on Windows rule (Critical severity, Windows platform) fires when the rate of file rename, overwrite, or deletion operations exceeds configured thresholds within a short time window. This is the primary signal for active destruction in progress.

In a wiper scenario, this rule triggers during the file overwrite phase - the point at which the malware is actively destroying data. The alert provides the affected host, the user context under which the destruction is running, and the velocity of file operations. An analyst who receives this alert at Critical severity should treat it as a confirmed impact event and begin containment immediately, without waiting for further correlation.

The same rule also catches ransomware encryption (since encryption involves mass file modification), making it a dual-purpose detection that covers both T1485 and T1486. The analyst differentiates between the two by examining the file operation type: encryption typically shows rename operations (adding a new extension), while destruction shows overwrite or delete operations.

Excessive Attempt To Disable Services

The Excessive Attempt To Disable Services rule (Critical severity, Windows platform) detects mass service stopping - the precursor step that wipers execute before beginning destruction. Disabling antivirus, backup agents, and database services clears the path for uninterrupted data destruction.

This rule fires before the actual destruction begins. If the SOC responds to service disabling fast enough, they can isolate the host and prevent the wiper from reaching the destruction phase. In practice, the gap between service disabling and file destruction is often 10-60 seconds in automated wiper deployments, and longer in manual operations where the attacker is executing commands interactively.

Custom detection recommendations

The built-in rules catch file-level destruction and service disabling. The following custom correlations extend detection to cover disk-level wiping, backup targeting, and specific wiper tooling:

Wiper malware analysis: what the SOC sees

Understanding what wiper behavior looks like in logs helps analysts respond faster. The following log patterns characterize active wiper deployment:

• Pre-destruction phase: The wiper disables defenses and eliminates recovery options. In Log360, this appears as a rapid sequence of service stop events targeting security and backup services, followed by vssadmin or wmic commands deleting shadow copies. The Excessive Attempt To Disable Services rule fires during this phase. The time window is typically 5-30 seconds.
• Active destruction phase: The wiper begins overwriting or deleting files. Windows file audit events (Event IDs 4663 and 4660) flood the log stream at abnormal velocity. The Suspicious Bulk File Modifications or Deletions on Windows rule fires. Analysts should immediately check the process responsible for the file operations - legitimate processes like backup software or deployment tools will have recognizable names and expected schedules. An unknown process performing bulk file operations outside maintenance windows is near-certain malicious activity.
• Disk-level phase (advanced wipers): Sophisticated wipers like HermeticWiper target the MBR, partition tables, and raw disk sectors. This activity may not generate Windows file audit events because it bypasses the file system layer. Detection requires Sysmon RawAccessRead events (Event 9) or EDR telemetry forwarded to Log360. If the SOC sees pre-destruction service disabling but no subsequent file audit events, that is itself an indicator that a disk-level wiper may be active - the absence of expected log data is a detection signal.

Investigation workflow

T1485 investigations require balancing containment urgency with evidence preservation. Wiped data is gone, but the forensic artifacts on the attacker's path to destruction are still recoverable if the analyst preserves them before remediation begins.

1. Isolate the affected host immediately: Pull the network cable or disable the switch port. Do not rely on software-based isolation - if the wiper has disabled security agents, software isolation may fail. Physical or network-level isolation is required.
2. Assess scope across the environment: Use Log360 correlated alerts to identify all hosts showing similar indicators (bulk file events, service stops, shadow copy deletion) within the same time window. Wipers spread via lateral movement - one affected host usually means more.
3. Determine destruction type: File-level or disk-level? File-level destruction leaves the OS bootable (files are deleted but the system functions). Disk-level destruction renders the system unbootable (MBR/partition table corrupted). This distinction determines the forensic approach and recovery path.
4. Trace the kill chain backward: From the destruction event, pivot to execution indicators (how the wiper was launched), then to lateral movement (how it reached the host), then to initial access (how the attacker entered the network). This reveals additional dormant footholds.
5. Create forensic images before remediation: Disk images of affected systems are critical for insurance claims, law enforcement referral, and post-incident analysis. Once remediation begins, evidence is lost.

Response and recovery

Recovery from data destruction depends on backup preparedness. The response workflow is different from ransomware because there is no negotiation option and no decryptor to wait for. Recovery is binary: backups are viable, or data is permanently lost.

• Verify backup integrity before restoring: Adversaries frequently target backup infrastructure as part of the destruction campaign. Verify that backups were not modified, encrypted, or deleted. Check backup agent logs for unauthorized access in the days preceding the incident.
• Restore from immutable or offline backups: If offline or immutable (write-once) backups exist, these are the most trustworthy recovery source. Tape backups and air-gapped storage are immune to network-based wiper propagation.
• Rebuild rather than repair disk-level damage: Systems with corrupted MBR or partition tables should be rebuilt from clean images, not repaired. MBR repair tools may succeed but leave residual compromise artifacts that the attacker can exploit for re-entry.
• Remediate the entry vector before restoring operations: Restoring systems without closing the initial access path invites repeat destruction. Identify and remediate the vulnerability or credential compromise that enabled the attack.
• Report to relevant authorities: Destructive attacks, especially those with nation-state indicators, should be reported to CISA (US), NCSC (UK), or the appropriate national CERT. These agencies provide additional threat intelligence and support.

Hardening against data destruction

Cross-technique context

Data destruction rarely occurs in isolation. The adversary traverses multiple techniques before reaching T1485:

• Initial Access (TA0001) provides the entry point - often through phishing, exploitation of public-facing applications, or valid account abuse.
• Execution (TA0002) launches the wiper binary or script on compromised hosts.
• T1490 (Inhibit System Recovery) eliminates shadow copies, backup catalogs, and boot configuration - clearing the path for irreversible damage.
• T1489 (Service Stop) disables security agents, backup services, and databases before the destruction phase.
• T1486 (Data Encrypted for Impact) is the parallel technique - some operations use encryption instead of destruction, and some (like NotPetya) disguise destruction as encryption.

Detecting at any upstream stage prevents the attacker from ever reaching T1485. The Ransomware Full Kill Chain scenario page traces the full multi-stage path from entry to impact with detection opportunities at every stage.

Need to explore ManageEngine Log360? Schedule a personalized demo

FAQ