Potential NFS Destructive Operation Burst
Description
Identifies a burst of successful NFS write activity combined with destructive REMOVE or RENAME operations from a single client to one export server within a one-minute window. Ransomware and destructive actors often encrypt, delete, or rename large numbers of files on mounted NFS shares; this aggregation surfaces that behavior using NFS opcode telemetry when file paths are not available on the wire.
Query · esql
from logs-network_traffic.nfs-*, packetbeat-* metadata _source
| eval
Esql.opcode = TO_UPPER(COALESCE(
JSON_EXTRACT(_source, "network_traffic.nfs.opcode"),
JSON_EXTRACT(_source, "nfs.opcode")
)),
Esql.status = TO_UPPER(COALESCE(
JSON_EXTRACT(_source, "network_traffic.nfs.status"),
JSON_EXTRACT(_source, "nfs.status")
))
| where Esql.opcode in ("WRITE", "REMOVE", "RENAME") and Esql.status == "NFS_OK" and
source.ip is not null and destination.ip is not null
| eval Esql.time_window = DATE_TRUNC(1 minutes, @timestamp)
| eval Esql.is_write = CASE(Esql.opcode == "WRITE", 1, 0),
Esql.is_destructive = CASE(Esql.opcode == "REMOVE" or Esql.opcode == "RENAME", 1, 0)
| stats
Esql.mutating_ops = COUNT(*),
Esql.write_ops = SUM(Esql.is_write),
Esql.destructive_ops = SUM(Esql.is_destructive),
Esql.values_opcodes = VALUES(Esql.opcode)
by Esql.time_window, source.ip, destination.ip
| where Esql.mutating_ops >= 100 and Esql.write_ops > 0 and Esql.destructive_ops >= 20
| keep source.ip, destination.ip, Esql.*
Implementation guide
This rule requires the Elastic network_traffic integration with the NFS protocol module enabled on a sensor that observes NFS traffic to monitored export servers.
Known false positives
- Backup deduplication engines, migration utilities, and filesystem sync tools can generate high volumes of legitimate NFS writes. Validate the source against known backup or storage-management hosts before escalating.
Analyst notes
Investigating Potential NFS Destructive Operation Burst
Remote encryption over NFS typically manifests as sustained successful WRITE activity paired with REMOVE/RENAME operations from one client IP against a single export. This rule aggregates mutating NFS opcodes because Packetbeat does not publish individual file paths in the NFS data stream.
Possible investigation steps
- Review
Esql.write_ops,Esql.destructive_ops, andEsql.values_opcodes, and comparesource.ipto approved backup or admin hosts. - Pivot to endpoint telemetry on the source for ransomware families, suspicious processes, or recent
mount.nfsactivity. - Inspect the export for ransom notes, mass extension changes, or abnormal file timestamps following the alert window.
- Correlate with preceding AUTH_SYS root UID or READDIR-heavy activity from the same client.
False positive analysis
- Scheduled backup, rsync-style sync, or VM storage migration from known infrastructure is the most common benign cause. Exception stable backup clients after validating opcode mix and timing against maintenance windows.
Response and remediation
- Isolate the source host from the export if ransomware is suspected and snapshot the export where possible.
- Revoke export access for the client IP and audit
/etc/exportsfor overly permissive entries. - Restore affected data from immutable backups after confirming the encryption stage has ended.