« Suspicious UID Change to Root via Python Multiple SonicWall Login Failures Followed by Successful Login »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.29

First Time Seen NFS AUTH_SYS Root UID Access

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

First Time Seen NFS AUTH_SYS Root UID Access

edit

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.

Rule type: new_terms

Rule indices:

  • logs-network_traffic.nfs*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

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

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.

Setup

edit

Setup

This rule requires the Elastic network_traffic integration (Packetbeat via Elastic Agent) with the NFS protocol module enabled on a sensor that observes NFS traffic to or from monitored exports (host agent, SPAN/mirror, or gateway).

Rule query

edit
data_stream.dataset:network_traffic.nfs and
network_traffic.nfs.rpc.cred.uid:0 and
network_traffic.nfs.rpc.auth_flavor:unix and
source.ip:* and destination.ip:*

Framework: MITRE ATT&CKTM

« Suspicious UID Change to Root via Python Multiple SonicWall Login Failures Followed by Successful Login »