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.ipand confirm whether it is an approved NFS client for the targeteddestination.ipexport server. - Review adjacent NFS operations from the same source for
READDIR,READ,WRITE, orREMOVEactivity that suggests enumeration, collection, or impact. - Validate export policy on the server (
/etc/exports,exportfs -v) forno_root_squash, overly broad client lists, or missingsec=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.ipat 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/RENAMEbursts from the same client that may indicate ransomware activity.
References
Related rules
- First Time Seen Memcached Writer
- First-Time Destructive MongoDB Command from a Client IP
- MySQL User-Defined Function Injection
- PostgreSQL COPY PROGRAM Command Execution
- Cassandra JavaScript UDF Creation