Loading

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.

Rule type: esql
Rule indices:

Rule Severity: medium
Risk Score: 47
Runs every:
Searches indices from: now-9m
Maximum alerts per execution: 5
References:

Tags:

  • Domain: Network
  • Use Case: Threat Detection
  • Use Case: Network Security Monitoring
  • Tactic: Impact
  • Data Source: Network Packet Capture
  • Resources: Investigation Guide

Version: 1
Rule authors:

  • Elastic

Rule license: Elastic License v2

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.

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.

  • 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.
  • 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.
  • 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.
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.*

Framework: MITRE ATT&CK