Potential NFS Destructive Operation Burst

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.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/07/31"
  3integration = ["network_traffic"]
  4maturity = "production"
  5min_stack_comments = "Requires ES|QL JSON_EXTRACT on _source to read NFS opcode and status fields."
  6min_stack_version = "9.4.0"
  7updated_date = "2026/07/31"
  8
  9[rule]
 10author = ["Elastic"]
 11description = """
 12Identifies a burst of successful NFS write activity combined with destructive REMOVE or RENAME operations from a single
 13client to one export server within a one-minute window. Ransomware and destructive actors often encrypt, delete, or
 14rename large numbers of files on mounted NFS shares; this aggregation surfaces that behavior using NFS opcode telemetry
 15when file paths are not available on the wire.
 16"""
 17false_positives = [
 18    """
 19    Backup deduplication engines, migration utilities, and filesystem sync tools can generate high volumes of legitimate
 20    NFS writes. Validate the source against known backup or storage-management hosts before escalating.
 21    """,
 22]
 23from = "now-9m"
 24language = "esql"
 25license = "Elastic License v2"
 26max_signals = 5
 27name = "Potential NFS Destructive Operation Burst"
 28note = """## Triage and analysis
 29
 30### Investigating Potential NFS Destructive Operation Burst
 31
 32Remote encryption over NFS typically manifests as sustained successful WRITE activity paired with REMOVE/RENAME
 33operations from one client IP against a single export. This rule aggregates mutating NFS opcodes because Packetbeat
 34does not publish individual file paths in the NFS data stream.
 35
 36### Possible investigation steps
 37
 38- Review `Esql.write_ops`, `Esql.destructive_ops`, and `Esql.values_opcodes`, and compare `source.ip` to approved backup
 39  or admin hosts.
 40- Pivot to endpoint telemetry on the source for ransomware families, suspicious processes, or recent `mount.nfs` activity.
 41- Inspect the export for ransom notes, mass extension changes, or abnormal file timestamps following the alert window.
 42- Correlate with preceding AUTH_SYS root UID or READDIR-heavy activity from the same client.
 43
 44### False positive analysis
 45
 46- Scheduled backup, rsync-style sync, or VM storage migration from known infrastructure is the most common benign cause.
 47  Exception stable backup clients after validating opcode mix and timing against maintenance windows.
 48
 49### Response and remediation
 50
 51- Isolate the source host from the export if ransomware is suspected and snapshot the export where possible.
 52- Revoke export access for the client IP and audit `/etc/exports` for overly permissive entries.
 53- Restore affected data from immutable backups after confirming the encryption stage has ended.
 54"""
 55references = ["https://attack.mitre.org/techniques/T1486/", "https://attack.mitre.org/techniques/T1039/"]
 56risk_score = 47
 57rule_id = "8e78b1a5-9674-4a96-8ce7-76ef54566a85"
 58setup = """## Setup
 59
 60This rule requires the Elastic **network_traffic** integration with the **NFS** protocol module enabled on a sensor that
 61observes NFS traffic to monitored export servers.
 62"""
 63severity = "medium"
 64tags = [
 65    "Domain: Network",
 66    "Use Case: Threat Detection",
 67    "Use Case: Network Security Monitoring",
 68    "Tactic: Impact",
 69    "Data Source: Network Packet Capture",
 70    "Resources: Investigation Guide",
 71]
 72timestamp_override = "event.ingested"
 73type = "esql"
 74
 75query = '''
 76from logs-network_traffic.nfs-*, packetbeat-* metadata _source
 77| eval
 78    Esql.opcode = TO_UPPER(COALESCE(
 79        JSON_EXTRACT(_source, "network_traffic.nfs.opcode"),
 80        JSON_EXTRACT(_source, "nfs.opcode")
 81    )),
 82    Esql.status = TO_UPPER(COALESCE(
 83        JSON_EXTRACT(_source, "network_traffic.nfs.status"),
 84        JSON_EXTRACT(_source, "nfs.status")
 85    ))
 86| where Esql.opcode in ("WRITE", "REMOVE", "RENAME") and Esql.status == "NFS_OK" and
 87    source.ip is not null and destination.ip is not null
 88| eval Esql.time_window = DATE_TRUNC(1 minutes, @timestamp)
 89| eval Esql.is_write = CASE(Esql.opcode == "WRITE", 1, 0),
 90    Esql.is_destructive = CASE(Esql.opcode == "REMOVE" or Esql.opcode == "RENAME", 1, 0)
 91| stats
 92    Esql.mutating_ops = COUNT(*),
 93    Esql.write_ops = SUM(Esql.is_write),
 94    Esql.destructive_ops = SUM(Esql.is_destructive),
 95    Esql.values_opcodes = VALUES(Esql.opcode)
 96  by Esql.time_window, source.ip, destination.ip
 97| where Esql.mutating_ops >= 100 and Esql.write_ops > 0 and Esql.destructive_ops >= 20
 98| keep source.ip, destination.ip, Esql.*
 99'''
100
101
102[[rule.threat]]
103framework = "MITRE ATT&CK"
104[[rule.threat.technique]]
105id = "T1486"
106name = "Data Encrypted for Impact"
107reference = "https://attack.mitre.org/techniques/T1486/"
108
109
110[rule.threat.tactic]
111id = "TA0040"
112name = "Impact"
113reference = "https://attack.mitre.org/tactics/TA0040/"
114
115[rule.alert_suppression]
116group_by = ["source.ip", "destination.ip"]
117missing_fields_strategy = "suppress"
118
119[rule.alert_suppression.duration]
120unit = "h"
121value = 1

Triage and analysis

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, and Esql.values_opcodes, and compare source.ip to approved backup or admin hosts.
  • Pivot to endpoint telemetry on the source for ransomware families, suspicious processes, or recent mount.nfs activity.
  • 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/exports for overly permissive entries.
  • Restore affected data from immutable backups after confirming the encryption stage has ended.

References

Related rules

to-top