File sharing protocols power the back office of nearly every enterprise — FTP for legacy data drops, SMB for Windows file servers, and NFS for Unix-to-Unix exports. Each protocol ships with anonymous or guest access modes that administrators routinely enable for convenience and forget to lock down. This article builds a deliberately vulnerable lab on Ubuntu that exposes all three services to anonymous reconnaissance, then demonstrates how an attacker on Kali Linux enumerates each one with Nmap, smbclient, and NetExec. By the end, the reader holds a complete, reproducible testbed for practicing file-share enumeration — the same workflow that surfaces real-world data exposure on every other engagement.

Table of Contents

• Why File Share Misconfigurations Matter
• Lab Environment
• Configuring vsftpd for Anonymous Access
• Enumerating the FTP Server
• Configuring Samba with Guest Access
• Enumerating the Samba Server
• Configuring NFS with Insecure Exports
• Enumerating the NFS Server
• One-Shot File Download with NetExec
• Mounting the Export with mount -t nfs
• Mitigation Strategies
• Final Analysis

Why File Share Misconfigurations Matter

File share misconfigurations consistently rank among the highest-impact findings on internal penetration tests. Unauthenticated access to an FTP, SMB, or NFS server frequently surfaces source code, backup archives, configuration files containing credentials, and PII that no perimeter control can recover. The three protocols covered in this article each present a different anonymous-access primitive: vsftpd exposes the anon_root directory under the ftp user, Samba exposes shares marked guest ok=yes, and NFS exposes any path listed in /etc/exports without root_squash. Operators who master all three enumeration workflows compress their initial-access timeline from hours to minutes.

Lab Environment

The lab uses two virtual machines on the same 192.168.1.0/24 subnet. The Ubuntu server hostname ignite at 192.168.1.9 hosts vsftpd, Samba, and the NFS kernel server. The attacker drives Kali Linux at 192.168.1.17 with Nmap, the standard FTP client, smbclient, and NetExec already installed. Every command in the article executes as root inside its respective VM, mirroring a quick lab build rather than a hardened production deployment.

Configuring vsftpd for Anonymous Access

vsftpd (Very Secure FTP Daemon) is the default FTP server on most Debian-derived distributions. Out of the box it binds to TCP port 21, enables local-user logins, and disables anonymous access. The lab build below flips that default and configures a passive anonymous share that any attacker on the network can read.

Installing vsftpd

The following command will install vsftpd packages as the only new dependency:

apt install vsftpd

The single-package install footprint is one of vsftpd’s strengths — the daemon ships with sane defaults and minimal moving parts, which is exactly why so many teams reach for it without revisiting the configuration.

Reviewing the Default Configuration

The default /etc/vsftpd.conf file shows the conservative posture that ships with the package. Use the following command read the file:

nano /etc/vsftpd.conf

The file shows: listen=NO (the daemon delegates to inetd unless overridden), listen_ipv6=YES, anonymous_enable=NO, and local_enable=YES. The anonymous_enable=NO line is the single most important default — leaving it untouched would prevent every attack demonstrated in this section.

Enabling Anonymous Access

The lab build now reverses the secure default by switching anonymous_enable to YES. This single line is the misconfiguration that powers every subsequent enumeration step.

The edited configuration shows anonymous_enable=YES alongside the unchanged local_enable=YES. With both flags active, the daemon will accept logins from local Linux users with their normal passwords and from the anonymous user with no password at all. In production, this combination represents a critical exposure — anyone who reaches port 21 can list and download whatever the ftp user can read.

Creating the FTP Directory and Sample File

The anonymous user inside vsftpd maps to the local ftp account, which on Debian-derived systems shares its home directory with /var/ftp. The lab creates a public subdirectory, hands ownership to the nobody user and nogroup group (the conventional unprivileged identity) and seeds it with a sample file by using following commands:

mkdir -p /var/ftp/pub

sudo chown nobody:nogroup /var/ftp/pub

cd /var/ftp/pub

echo "Welcome to Hacking Articles" > note.txt

The four commands prepare the share. The pub directory is the conventional name for an anonymous FTP drop folder — dating back to the original Internet FTP archives at MIT and Berkeley — and is exactly what an attacker expects to find. The note.txt file inside it gives the enumeration workflow a tangible artefact to retrieve.

Hardening Anonymous Mode

With the sample directory in place, the configuration file gains the anonymous-mode tuning block. These directives root the anonymous user inside /var/ftp, suppress the password prompt, mask the underlying UID and GID so the share owner cannot be enumerated, and constrain the passive-mode port range to 40000-50000 for predictable firewalling.

# Point users at the directory we created earlier.
anon_root=/var/ftp/

# Stop prompting for a password on the command line.
no_anon_password=YES

# Show the user and group as ftp:ftp, regardless of the owner.
hide_ids=YES

# Limit the range of ports that can be used for passive FTP
pasv_min_port=40000
pasv_max_port=50000

The highlighted block in the screenshot adds anon_root=/var/ftp/, no_anon_password=YES, hide_ids=YES, and the pasv_min_port=40000 / pasv_max_port=50000 pair. The hide_ids=YES line is particularly noteworthy from a defensive standpoint — it exists specifically so administrators can offer anonymous shares without leaking which Linux account owns each file. The configuration above represents the lab’s deliberately permissive endpoint, ready for restart.

Restarting the Service

A clean service restart applies the new configuration and the command to restart it is as follows:

service vsftpd restart

The empty output is the expected success signal on systemd-managed distributions — vsftpd is now bound to port 21 and ready to accept anonymous logins.

Enumerating the FTP Server

With the lab server live, the attacker on Kali pivots to enumeration. The two commands below mirror the canonical workflow: a service-detection scan with Nmap to confirm anonymous access is allowed, followed by an interactive FTP session to retrieve the contents of the share.

Nmap Service Detection

Nmap’s -A flag enables OS detection, version detection, script scanning, and traceroute in a single pass, which, with the following command, will help us to gather all the necessary information:

nmap -A -p21 192.168.1.9

The output identifies vsftpd 3.0.5 listening on port 21 and — critically — the ftp-anon NSE script reports “Anonymous FTP login allowed (FTP code 230)” and lists the pub directory inside the anonymous root. This single Nmap line tells the operator everything they need: anonymous access is on, the share is reachable, and the workflow now moves to direct interaction.

FTP Session and File Retrieval

We will now login through FTP session by using the following set of commands:

ftp 192.168.1.9
#Login as: Anonymous
ls
cd pub
ls
get note.txt

The operator authenticates as Anonymous, is greeted with code 230 (login successful), runs ls to enumerate the anonymous root, navigates into pub, and downloads note.txt with the get command. The transfer completes in under a second — a 28-byte file in this lab, but the same workflow scales identically to multi-gigabyte database dumps and source-code archives that real-world misconfigured servers expose every day.

Configuring Samba with Guest Access

Samba implements the SMB/CIFS protocol on Linux and serves as the bridge between Linux servers and Windows clients. Like vsftpd, Samba ships with conservative defaults that the lab deliberately weakens. The smb.conf file below defines a guest-accessible share that any unauthenticated SMB client on the network can browse and download from.

Installing Samba

Use the following command to install samba:

apt install samba

The apt installer pulls Samba alongside its client libraries and the supporting tdb-tools package. Once the install completes, the daemon is ready to be configured — although it does not yet expose any shares because the default smb.conf only declares the [global] and [printers’] sections.

Editing smb.conf

To edit smb.conf, use the following combination of the commands:

cd /etc/samba/
ls -al
nano smb.conf

The /etc/samba directory listing shows the canonical smb.conf file, the gdbcommands debugging file, and the tls subdirectory for certificate material. The lab edits smb.conf directly with nano — a deliberate choice for clarity, although production deployments should use the testparm utility to validate every change before applying it.

Defining the [shares] Section

Appending a single [shares] block to smb.conf is enough to publish a fully writable, guest-accessible share. The seven directives below combine to expose /var/www on the network with no authentication.

[shares]
path = /var/www/
available = yes
read only = no
browsable = yes
public = yes
writable = yes
guest ok = yes

The block defines path=/var/www/, available=yes, read only=no, browsable=yes, public=yes, writable=yes, and guest ok=yes. Every line contributes to the exposure: guest ok=yes maps unauthenticated clients to the anonymous account, public=yes echoes the same intent in legacy syntax, browsable=yes makes the share visible during enumeration, and writable=yes plus read only=no lets attackers stage payloads or overwrite content. Pointing the share at /var/www — a directory commonly served by a webserver — compounds the risk by creating a write-anywhere primitive that backs onto an HTTP endpoint.

Populating the Share

To give the enumeration workflow a verifiable retrieval target use the following commands:

cd /var/www/
ls
cat file.txt

The screenshot confirms /var/www holds a sample file.txt containing the string “Follow Hackin Articles” alongside the standard html subdirectory.

Enumerating the Samba Server

Two industry-standard tools handle Samba enumeration: NetExec for fast share discovery across many hosts, and smbclient for interactive session work against a single host. The two complement each other perfectly.

NetExec Share Discovery

NetExec uses the following command to authenticate as the guest user with an empty password and immediately enumerates the available shares

nxc smb 192.168.1.9 --shares -u 'guest' -p ''

The output identifies the host as the IGNITE Unix Samba server, confirms guest authentication succeeded with the [+] IGNITE\guest: (Guest) banner, and lists three shares: print$ (the default printer driver share), shares (with READ permissions for the guest principal), and IPC$ (the inter-process communication share). The READ permission against shares is the green light to launch an interactive session.

smbclient Interactive Session

The following commands will return the same share inventory NetExec produced, along with the smbclient command, which opens an interactive session against the shares export:

smbclient -N -L //192.168.1.9
smbclient //192.168.1.9/shares -N
ls
get file.txt

The interactive prompt also exposes a noteworthy artefact: the server falls back to SMB1 for workgroup listing, which the smbXcli_negprot_smb1_done error confirms is no longer enabled — a small but welcome hardening default.

Configuring NFS with Insecure Exports

NFS (Network File System) is the canonical Unix-to-Unix file sharing protocol. Unlike FTP and SMB, NFS does not authenticate users at the protocol level by default — it trusts the client’s declared UID. The combination of insecure export options below intentionally weaponises this trust model for the lab.

Installing the NFS Kernel Server

To install NFS Kernel Server use the following command:

apt install nfs-kernel-server -y

The above command installs the NFS server alongside its supporting libraries: keyutils, libnfsidmap1, nfs-common, and rpcbind. The rpcbind dependency is significant — it manages the portmapper service on TCP/UDP 111 that NFS clients query to locate the mount and NFS daemons. Defenders should remember that any open rpcbind port is a strong indicator that an NFS server is reachable somewhere on the host.

Creating the Export Directory

To create and give permissions to the export directory, use the set of following commands:

mkdir -p /srv/nfs/public
chmod 777 /srv/nfs/public
cd /srv/nfs/public    
echo "join Ignite Technologies" > data.txt

The lab creates /srv/nfs/public with world-writable 777 permissions and seeds it with a sample data.txt file. Combining 777 directory permissions with NFS’s no_root_squash export option (added below) creates a textbook privilege escalation surface — an attacker who mounts the share as root can write SUID binaries that execute with root privileges on the next session against the host.

Editing /etc/exports

To edit the export file, use the following command:

nano /etc/exports

The /etc/exports file is the access-control list for every directory the NFS server publishes. The kernel re-reads this file whenever exportfs runs, so configuration changes apply without restarting the daemon.

Defining the Insecure Export

A single line at the bottom of /etc/exports publishes /srv/nfs/public to every client on the network with the most permissive options NFS supports.

The line /srv/nfs/public *(rw,sync,no_subtree_check,no_root_squash,insecure) combines four risky options. The asterisk wildcard exports the share to any client IP. rw grants both read and write access. no_root_squash is the most dangerous flag in the entire NFS lexicon — it disables the default UID-mapping that translates remote root requests to the unprivileged nobody user, allowing any client root to act as local root on the share. The insecure option permits client connections from ports above 1024, removing the historical safeguard that required NFS clients to use privileged source ports.

Applying the Export

Using the following commands will reload every export table entry, and the systemctl restart cycles the NFS kernel server to pick up any underlying changesexportfs -a

systemctl restart nfs-kernel-server

The empty output indicates a clean apply — the share is now live and discoverable across the network.

Enumerating the NFS Server

NetExec’s NFS protocol module ports the classic showmount and rpcinfo workflow into the same interface used for SMB and other protocols. Two commands cover both the discovery phase and the file-listing phase.

nxc nfs 192.168.1.9 --enum-shares
nxc nfs 192.168.1.9 --share '/srv/nfs/public' --ls '/'

NFS export /srv/nfs/public (rw-) exposed via no_root_squash (root escape:True), listing root contents including data.txt (25 bytes). Attackers mount via mount -t nfs 192.168.1.9:/srv/nfs/public /mnt/loot, extract files as root, and deploy SUID-root binaries for persistence. Priority: disable no_root_squash and restrict exports.

One-Shot File Download with NetExec

NetExec’s NFS module ships a –get-file action that downloads a single file from a remote export without performing any local mount. The command takes two positional arguments: the remote file path relative to the share root, and the local destination path. This is the fastest path from “I know the file exists” to “I hold the file on disk.”

nxc nfs 192.168.1.9 --share /srv/nfs/public/ --get-file data.txt data.txt
cat data.txt

NetExec successfully retrieves data.txt from NFS share: supports NFSv3/4, confirms no_root_squash (root escape:True), downloads file (“File successfully downloaded”), and extracts contents (“join Ignite Technologies”). Executes from user home directory—no root, no mounts, no forensic artifacts.

Mounting the Export with mount -t nfs

NetExec enables fast file-by-file downloads without shell access, while NFS mounting provides full filesystem semantics—ls, find, grep, cp, and SUID execution against the remote export as a local directory—transforming no_root_squash into a privilege escalation primitive.mkdir /tmp/nfs

mount -t nfs 192.168.1.9:/srv/nfs/public /tmp/nfs
ls -la /tmp/nfs
cat data.txt

NFS mount (mkdir /tmp/nfs && mount -t nfs 192.168.1.9:/srv/nfs/public /tmp/nfs) exposes /tmp/nfs as drwxrwxrwx root:root containing data.txt (25B, root-owned); no_root_squash maps Kali root to server root, enabling SUID-root binary persistence—confirmed by matching cat data.txt contents from NetExec.

Mitigation Strategies

The exposures demonstrated above all stem from a handful of configuration choices. Reversing each one closes the corresponding attack vector without breaking legitimate file-sharing workflows.

FTP Hardening

• Disable Anonymous Access: Set anonymous_enable=NO in /etc/vsftpd.conf unless a documented business case justifies the exposure; even then, prefer SFTP over OpenSSH for any file drop that crosses untrusted networks.
• Enforce TLS: Set ssl_enable=YES with force_local_data_ssl=YES and force_local_logins_ssl=YES so credentials and content never traverse the wire in cleartext.
• Restrict Network Exposure: Bind vsftpd to internal interfaces only, and front the daemon with a host-based firewall that limits port 21 to known administrative subnets.

Samba Hardening

• Disable Guest Access: Remove guest ok=yes and public=yes from every share, set map to guest = Never in the [global] section, and require valid Linux accounts for every connection.
• Disable SMB1: Set min protocol = SMB2 in [global] to prevent fallback to the historically broken SMB1 dialect; modern clients negotiate SMB3 by default.
• Restrict Share Paths: Never publish /var/www, /etc, or any path that backs onto another service; isolated share roots like /srv/samba/<sharename> contain blast radius if access controls fail.

NFS Hardening

• Enable root_squash: Remove no_root_squash from every export line; the default root_squash maps remote root requests to nobody and shuts down the SUID-binary persistence vector entirely.
• Restrict Export Wildcards: Replace the * wildcard with explicit client IP addresses or CIDR ranges so only known hosts can mount the share.
• Enable Kerberos Authentication: Configure NFSv4 with sec=krb5p to authenticate and encrypt every NFS operation; the protocol’s default UID-trust model collapses without Kerberos in any zero-trust environment.
• Firewall Portmapper and NFS Ports: Block TCP/UDP 111 (rpcbind), 2049 (NFS), and the dynamic mountd port at the host firewall for every untrusted source.

Final Analysis

The three protocols covered in this article — FTP, SMB, and NFS — collectively underpin most enterprise file sharing. Each one ships with conservative defaults, and each one is routinely weakened by administrators chasing convenience. The lab build above reproduces the exact misconfigurations that surface on real engagements: anonymous FTP enabled with hide_ids masking ownership, Samba shares marked guest ok=yes pointing at sensitive paths, and NFS exports with no_root_squash and wildcard host lists. The matching enumeration workflows — Nmap, smbclient, and NetExec — collapse discovery and exploitation into a handful of commands the operator masters in an afternoon.

Defenders win this fight by treating file-share configuration as security-critical infrastructure rather than back-office plumbing. Every misconfiguration demonstrated here can be detected with a single grep against the relevant config file, and every fix takes one line. Organisations that audit /etc/vsftpd.conf, /etc/samba/smb.conf, and /etc/exports across the fleet on a quarterly cadence — and that pair the audit with network-level scans for ports 21, 445, and 2049 from untrusted segments — close every primitive shown in this article. The lab built above is the testbed for both sides of that engagement: the offensive operator practising the kill chain, and the defender validating that their controls actually catch it.