A file share that any authenticated account can browse and write to is a ready-made staging area, discovery map and ransomware target. D3-RFAM Remote File Access Mediation is the MITRE D3FEND countermeasure for that gap: D3FEND defines it as "the process of managing and securing access to file systems over a network to ensure that only authorized users or processes can interact with remote files", gives it the synonym File Share Access Mediation, and places it in the Isolate tactic under Network Resource Access Mediation (D3-NRAM). This card covers what D3-RFAM isolates, which ATT&CK techniques D3FEND relates to it, where it is enforced on SMB, NFS and cloud file services, how to verify it and where it stops helping. It is written for infrastructure, storage and detection engineers. For the parent technique see D3-NRAM Network Resource Access Mediation, and for the whole family the MITRE D3FEND Access Mediation Implementation Guide.
Key takeaways
- D3-RFAM is the gate on remote files. It decides which users and processes may list, read, write or delete files reached over a network, through share permissions, export rules and storage policies.
- D3FEND's mapping is inferred from the File artefact. The 15 directly related ATT&CK techniques are those that access, create, modify, delete or encrypt a File, such as T1083, T1005, T1074.001 and T1486.
- Write and delete grants matter most. Staging, tampering, deletion and encryption all need write access; scoping write to named owners removes most of the leverage a stolen account has on a share.
- Visibility is not access. Access-based enumeration hides folders, but only share and file permissions actually block reads and writes.
- Service accounts hold the widest grants. Backup agents, sync jobs and deployment tools often have write on many shares; they are the identities to scope first.
D3-RFAM at a glance
| Field | D3-RFAM Remote File Access Mediation |
|---|---|
| D3FEND ID | D3-RFAM |
| Tactic | Isolate |
| Parent technique | Network Resource Access Mediation (D3-NRAM), itself under Access Mediation |
| Synonym | File Share Access Mediation |
| Digital artefact | File (D3FEND: the technique "isolates" a File) |
| Protocols named by D3FEND | SFTP and SMB, as examples of secure remote file access |
| D3FEND reference | NIST SP 800-53 Rev. 5 |
| Typical enforcement points | SMB share and NTFS permissions, NFS export options, SFTP server configuration, cloud file and object storage policies |
| Main limitation | Acts on authenticated identities: a stolen account or service credential with a valid grant passes |
What D3-RFAM does
D3FEND's article describes the technique as controlling how users or processes access file systems from remote locations, which involves secure connections and enforced permissions to prevent unauthorised access. Its examples are shared drives and cloud storage reached from remote offices or home networks. In practice that splits into three decisions, each made at a different layer:
- Who may connect: authentication to the file service (Kerberos or NTLM for SMB, the
sec=flavour for NFS, keys or certificates for SFTP). - What they may do: share-level and file-level permissions, export options such as read-only and root squashing, bucket or container policies.
- How the session is protected: signing and encryption of the file protocol so a mediated session cannot be altered or read in transit.
D3-RFAM is the remote counterpart of D3-LFP Local File Permissions: the same file can be protected by both, and on Windows the effective right is the more restrictive of the share and NTFS permissions.
ATT&CK techniques D3FEND relates to D3-RFAM
Relationship type: inferred only. D3FEND links D3-RFAM to ATT&CK because both act on the File artefact; it describes these offensive mappings as "inferred, experimental" (checked November 2026). The table lists the 15 enterprise techniques whose own D3FEND entry names File directly. The D3FEND web page shows a much longer list, because techniques acting on sub-types of File (executables, scripts, configuration files) are inherited; that longer list describes host activity more than anything a network file permission prevents, so it is not repeated here. All IDs were checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation | What remote file mediation changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1083 | File and Directory Discovery | Accesses File | Partial: enumeration of remote shares shrinks to what the identity may list |
| T1005 | Data from Local System | Accesses File | Limited: acts on the local host; relevant only where local paths are mapped shares |
| T1119 | Automated Collection | Accesses File | Partial: scripted collection from shares is bounded by read grants |
| T1552.001 | Credentials In Files | Accesses File | Partial: scripts and configs holding secrets on shares should be readable only by their owners |
| T1074.001 | Local Data Staging | May create File | Limited: staging on the local host; remote staging needs a writable share |
| T1036.005 | Match Legitimate Resource Name or Location | May create File | Strong where trusted share paths accept writes only from owners |
| T1036.006 | Space after Filename | Creates File | Partial: needs write access where victims will open the file |
| T1564.006 | Run Virtual Instance | Creates File | Limited: mainly a host behaviour |
| T1564.012 | File/Path Exclusions | Creates File | Partial: writing into excluded share paths requires write access there |
| T1072 | Software Deployment Tools | Adds File | Partial: deployment shares writable only by the deployment identity limit tampering |
| T1220 | XSL Script Processing | Adds File | Limited: mainly a host behaviour |
| T1565.001 | Stored Data Manipulation | Modifies File | Strong where write is limited to the owning application identity |
| T1070.004 | File Deletion | Deletes File; may modify File | Strong for remote files: delete rights scoped to owners |
| T1486 | Data Encrypted for Impact | Encrypts File | Partial: a compromised account encrypts only what it can write, so narrow write grants limit the blast radius |
| T1566.003 | Spearphishing via Service | Produces File | Limited: delivery usually arrives through a third-party service |
Closely related techniques that D3FEND attaches to the parent D3-NRAM through the Network Resource artefact, not to D3-RFAM, include T1039 Data from Network Shared Drive and T1080 Taint Shared Content. See T1083 File and Directory Discovery, MITRE ATT&CK T1486 Data Encrypted for Impact and MITRE ATT&CK T1039 Data from Network Shared Drive.
Where it is implemented
| File service | Mediation controls | Session protection | Decision telemetry |
|---|---|---|---|
| SMB shares (Windows, NAS, Samba) | Share permissions plus NTFS ACLs by group; no write for Everyone, Authenticated Users or Domain Users; access-based enumeration | SMB signing and encryption, SMB1 removed, guest access off | Windows events 5140 and 5145 |
| NFS exports | Client specification by host or network, ro unless write is needed, root_squash, all_squash where appropriate | sec=krb5, krb5i or krb5p; xprtsec=mtls for RPC-with-TLS | Server and Kerberos logs |
| SFTP servers | Per-account chroot or home directory, key-based authentication, no shell for transfer-only accounts | SSH transport | Server authentication and transfer logs |
| Cloud file and object storage | Policies naming specific principals, account-level public access blocks, no wildcard writers, private network endpoints | TLS enforced by policy | Data-plane access logs and policy-change logs |
Product categories are examples, not recommendations. The settings below come from operating system documentation.
Windows SMB
Microsoft documents that Windows 11 24H2 and Windows Server 2025 require SMB signing on all outbound and inbound connections by default, with guest fallback disabled; earlier releases required it only for SYSVOL and NETLOGON connections to domain controllers. The same documentation describes an SMB client encryption mandate, SMB NTLM blocking for outbound connections, minimum and maximum SMB dialect settings, and an authentication rate limiter that adds a two-second delay after each failed NTLM or local KDC Kerberos attempt. The transport side is covered in the SMB Protocol Security and Signing Guide; D3-RFAM adds the permission layer on top.
Access-based enumeration hides files and folders a user cannot access. Microsoft's DFS documentation is explicit that it "doesn't block access": users who know a path can still request it, and only share and NTFS permissions protect content. Treat ABE as discovery reduction against T1083, not as an access control.
NFS
The Linux exports(5) manual states that root_squash is the default and maps requests from uid 0 to the anonymous user, that sec=sys is the default flavour and has no cryptographic security, and that krb5, krb5i and krb5p add authentication, integrity and privacy. Exports are read-only unless rw is set. Review every export for no_root_squash, wildcard client specifications and sec=sys on networks that are not tightly controlled.
Where identity fits
The broadest file share grants are often held by non-human identities: backup agents with read on every volume, sync and migration tools, deployment service accounts that write to software distribution shares, and application accounts that write to data drops. A stolen credential for one of these accounts gives an attacker the same reach, including the ability to encrypt or delete at scale. Give each service account write only to its own path, prefer group managed service accounts or workload identities over static passwords, and alert when a service account touches shares outside its normal set. See the Unstructured Data and File Share Security Guide and the Backup Identity Isolation Guide.
Implementation steps
- Inventory remote file services. List every SMB share, NFS export, SFTP endpoint and cloud file or storage location, with an owner and the groups and service accounts holding write or delete.
- Turn on decision logging first. Enable the Audit File Share and Audit Detailed File Share subcategories on Windows file servers (events 5140 and 5145) and data-plane logging for cloud storage, so the effect of later changes is visible.
- Remove broad write and delete. Take write away from Everyone, Authenticated Users, Domain Users and wildcard principals on every high-value location. This is the change that limits T1486, T1565.001 and T1070.004 on shares.
- Scope reads and listing. Restrict sensitive shares to named groups, turn on access-based enumeration and move credential-bearing scripts out of widely readable paths.
- Harden the protocol. Require SMB signing (and encryption for sensitive shares), remove SMB1 and guest access, move NFS exports off
sec=syswhere Kerberos is available, and keeproot_squash. - Test in rings with rollback. Export current ACLs and export files before each change, apply to a pilot group of shares, review 5145 failure events and helpdesk tickets for a business cycle, then extend. Rollback is restoring the exported ACL or export file.
- Time-limit exceptions. Give temporary write grants an expiry and a named approver, and alert on permission changes that widen access.
How to verify it works
- Write test: with a standard test account, try to create, rename and delete a file on each high-value share and export. Expect a denial and, on Windows, a 5145 failure event where the denial is at share level (NTFS-level denials do not generate 5145 failures, so check the NTFS audit too).
- Enumeration test: browse the namespace as a standard user; only folders the user can open should appear.
- Service account test: confirm each backup, sync and deployment account can write only to its own paths.
- Protocol test: confirm unsigned SMB sessions and SMB1 connections are refused, and that NFS clients using
sec=sysare refused on Kerberos-only exports. - Drift test: widen a test share permission or storage policy and confirm an alert fires.
| Metric (example, not a standard) | What it shows | Direction |
|---|---|---|
| High-value shares and exports writable by broad groups or wildcards | Exposure to tampering, deletion and encryption | Zero |
| Share of remote file locations with a named owner | Whether grants can be reviewed | Rising to 100% |
| Service accounts with write on more than one unrelated share | Blast radius of one stolen credential | Falling |
NFS exports using sec=sys or no_root_squash | Weak authentication paths | Falling, each with a recorded exception |
| Permission changes that widened access, reviewed within a week | Drift control | All reviewed |
Limits, bypasses and failure patterns
- Valid credentials pass: D3-RFAM grants what the identity is allowed. A stolen user or service account reads and writes everything it holds; pair mediation with D3-RAPA Resource Access Pattern Analysis to catch abnormal volumes.
- Share permissions read as the whole story: a share set to Read for Everyone is still writable through a second share on the same folder, or through an administrative share, if NTFS allows it.
- Nested groups: a narrow-looking group that nests Domain Users quietly restores broad access.
- ABE treated as a control: hidden folders remain reachable by anyone who knows the path and holds permission.
- Host-level compromise: once an attacker runs code on the file server with administrative rights, remote mediation is behind them; host controls and backups take over.
- Forgotten paths: legacy SMB1 shares, test exports and storage locations created for a migration that kept broad access after the project ended.
Framework mapping
| Framework | Reference | Relationship to D3-RFAM |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 Access Enforcement, AC-6 Least Privilege | Grant and deny decisions on remote files under least privilege |
| NIST SP 800-53 Rev 5 | AC-17 Remote Access | Access to file systems from remote locations |
| MITRE ATT&CK mitigations | M1022 Restrict File and Directory Permissions, M1035 Limit Access to Resource Over Network | Closest in intent (NHI Mgmt Group mapping, not D3FEND) |
| MITRE D3FEND | D3-LFP Local File Permissions | Same control applied on the host |
D3FEND cites SP 800-53 Rev. 5 as its reference for D3-RFAM; the specific control rows are NHI Mgmt Group's mapping by control intent.
Practitioner checklist
- Inventory SMB shares, NFS exports, SFTP endpoints and cloud file locations with owners and writers.
- Enable file share auditing (5140, 5145) and cloud data-plane logs before changing permissions.
- Remove write and delete from broad groups and wildcard principals on high-value locations.
- Scope each service account's write access to its own paths.
- Require SMB signing, remove SMB1 and guest access, and use Kerberos flavours for NFS where possible.
- Treat access-based enumeration as discovery reduction, not access control.
- Export ACLs before changes and roll out in pilot rings.
- Run denial tests with standard and service test accounts each quarter.
Standards and references
- MITRE D3FEND: Remote File Access Mediation (D3-RFAM)
- MITRE D3FEND: Network Resource Access Mediation (D3-NRAM)
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (D3FEND reference)
- Microsoft Learn: SMB security hardening
- Microsoft Learn: Enable access-based enumeration on a namespace
- Microsoft Learn: Event 5145, a network share object was checked
- Linux man-pages: exports(5) NFS server export table
Related NHI Mgmt Group resources: D3-NRAM Network Resource Access Mediation · Unstructured Data and File Share Security Guide · SMB Protocol Security and Signing Guide · MITRE D3FEND Access Mediation Implementation Guide