First Time Seen NFS AUTH_SYS Root UID Access

Identifies the first source and destination IP pair observed in a five-day history window where an NFS client asserts AUTH_SYS (RPC UNIX) credentials with UID 0 (root). NFSv3 and NFSv4 clients can claim arbitrary UIDs through AUTH_SYS, and weak export controls may honor root-equivalent access from unexpected hosts. This is a common precursor to unauthorized mounts, sensitive file reads, and remote encryption of exported shares.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2026/06/25"
  3integration = ["network_traffic"]
  4maturity = "production"
  5updated_date = "2026/06/25"
  6
  7[rule]
  8author = ["Elastic"]
  9description = """
 10Identifies the first source and destination IP pair observed in a five-day history window where an NFS client asserts
 11AUTH_SYS (RPC UNIX) credentials with UID 0 (root). NFSv3 and NFSv4 clients can claim arbitrary UIDs through AUTH_SYS,
 12and weak export controls may honor root-equivalent access from unexpected hosts. This is a common precursor to
 13unauthorized mounts, sensitive file reads, and remote encryption of exported shares.
 14"""
 15false_positives = [
 16    """
 17    Legitimate NFS root squashing misconfiguration, administrative automation, or backup appliances may present UID 0
 18    from known infrastructure. Confirm the source IP against approved NFS client inventories before closing.
 19    """,
 20]
 21from = "now-9m"
 22index = ["logs-network_traffic.nfs*"]
 23language = "kuery"
 24license = "Elastic License v2"
 25name = "First Time Seen NFS AUTH_SYS Root UID Access"
 26note = """## Triage and analysis
 27
 28### Investigating First Time Seen NFS AUTH_SYS Root UID Access
 29
 30NFS AUTH_SYS allows the client to assert UID/GID values on the wire. UID 0 maps to superuser access on many exports unless root squashing or Kerberos (RPCSEC_GSS) is enforced. Attackers abuse this to read secrets, traverse exports, or stage ransomware writes without a local root shell on the NFS server. This rule uses a five-day history window to identify the first observed source and destination IP pair presenting root credentials.
 31
 32### Possible investigation steps
 33
 34- Identify `source.ip` and confirm whether it is an approved NFS client for the targeted `destination.ip` export server.
 35- Review adjacent NFS operations from the same source for `READDIR`, `READ`, `WRITE`, or `REMOVE` activity that suggests enumeration, collection, or impact.
 36- Validate export policy on the server (`/etc/exports`, `exportfs -v`) for `no_root_squash`, overly broad client lists, or missing `sec=krb5`.
 37- Check endpoint telemetry on the source host for tooling such as `showmount`, `mount.nfs`, or Impacket-style NFS abuse.
 38
 39### False positive analysis
 40
 41- Known backup, imaging, or virtualization platforms sometimes mount exports as root from fixed infrastructure IPs. Create exceptions for those sources only after confirming stable client identity and expected operation mix.
 42- Migration or DR runbooks may temporarily mount with root to preserve ownership. Correlate with change tickets and bounded maintenance windows.
 43
 44### Response and remediation
 45
 46- Block unauthorized `source.ip` at the host firewall or export ACL and rotate any credentials read from the export.
 47- Enforce `root_squash`, narrow client allowlists, and RPCSEC_GSS on sensitive exports.
 48- Hunt for follow-on `WRITE`/`RENAME` bursts from the same client that may indicate ransomware activity.
 49"""
 50references = ["https://attack.mitre.org/techniques/T1213/", "https://attack.mitre.org/techniques/T1039/"]
 51risk_score = 47
 52rule_id = "35ef761a-7136-4cb9-a32d-4e7abddb3bac"
 53setup = """## Setup
 54
 55This rule requires the Elastic **network_traffic** integration (Packetbeat via Elastic Agent) with the **NFS** protocol
 56module enabled on a sensor that observes NFS traffic to or from monitored exports (host agent, SPAN/mirror, or gateway).
 57"""
 58severity = "medium"
 59tags = [
 60    "Domain: Network",
 61    "Use Case: Threat Detection",
 62    "Use Case: Network Security Monitoring",
 63    "Tactic: Collection",
 64    "Data Source: Network Packet Capture",
 65    "Resources: Investigation Guide",
 66]
 67timestamp_override = "event.ingested"
 68type = "new_terms"
 69
 70query = '''
 71data_stream.dataset:network_traffic.nfs and
 72network_traffic.nfs.rpc.cred.uid:0 and
 73network_traffic.nfs.rpc.auth_flavor:unix and
 74source.ip:* and destination.ip:*
 75'''
 76
 77
 78[[rule.threat]]
 79framework = "MITRE ATT&CK"
 80[[rule.threat.technique]]
 81id = "T1039"
 82name = "Data from Network Shared Drive"
 83reference = "https://attack.mitre.org/techniques/T1039/"
 84
 85[[rule.threat.technique]]
 86id = "T1213"
 87name = "Data from Information Repositories"
 88reference = "https://attack.mitre.org/techniques/T1213/"
 89
 90
 91[rule.threat.tactic]
 92id = "TA0009"
 93name = "Collection"
 94reference = "https://attack.mitre.org/tactics/TA0009/"
 95
 96[rule.new_terms]
 97field = "new_terms_fields"
 98value = ["source.ip", "destination.ip"]
 99[[rule.new_terms.history_window_start]]
100field = "history_window_start"
101value = "now-5d"

Triage and analysis

Investigating First Time Seen NFS AUTH_SYS Root UID Access

NFS AUTH_SYS allows the client to assert UID/GID values on the wire. UID 0 maps to superuser access on many exports unless root squashing or Kerberos (RPCSEC_GSS) is enforced. Attackers abuse this to read secrets, traverse exports, or stage ransomware writes without a local root shell on the NFS server. This rule uses a five-day history window to identify the first observed source and destination IP pair presenting root credentials.

Possible investigation steps

  • Identify source.ip and confirm whether it is an approved NFS client for the targeted destination.ip export server.
  • Review adjacent NFS operations from the same source for READDIR, READ, WRITE, or REMOVE activity that suggests enumeration, collection, or impact.
  • Validate export policy on the server (/etc/exports, exportfs -v) for no_root_squash, overly broad client lists, or missing sec=krb5.
  • Check endpoint telemetry on the source host for tooling such as showmount, mount.nfs, or Impacket-style NFS abuse.

False positive analysis

  • Known backup, imaging, or virtualization platforms sometimes mount exports as root from fixed infrastructure IPs. Create exceptions for those sources only after confirming stable client identity and expected operation mix.
  • Migration or DR runbooks may temporarily mount with root to preserve ownership. Correlate with change tickets and bounded maintenance windows.

Response and remediation

  • Block unauthorized source.ip at the host firewall or export ACL and rotate any credentials read from the export.
  • Enforce root_squash, narrow client allowlists, and RPCSEC_GSS on sensitive exports.
  • Hunt for follow-on WRITE/RENAME bursts from the same client that may indicate ransomware activity.

References

Related rules

to-top