Field Reports

Insecure File Share Permissions

Field Report: The Danger of Insecure Shares

In this report, we dive into a classic case of insecure file share permissions that led to Domain Administrator access. The root cause isn’t a “public” or “guest” share; it’s the common practice of granting broad access to groups like Domain Users or Authenticated Users for convenience. As this penetration test proved, all it takes is one overlooked folder for a low-level account to become a Domain Administrator.

The Entry Point: Auditing Internal Shares

While authenticated as a standard domain user (After obtaining credentials from a user using weak and easily guessable passwords). I obtained access to the Active Directory by testing for generic users and user accounts gathered through Open Source Intelligence. Using a list of common usernames found, I performed a password spray attack against the Kerberos service. To do this I used the Kerbrute tool:

#Enumerating valid users
kerbrute userenum --dc 172.16.8.5 -d client.local osint_usernames.txt 

#Password spraying valid users
kerbrute passwordspray --dc 172.16.8.5 -d client.local Password@12345

With valid credentials, I began auditing internal network shares. To do this, I use Netexec. You can find a great cheat sheet on how to use the tool here.

#Validate Credentials
netexec 172.16.8.5 -u='username' -p='Password@12345'

#Auditing shares for access
netexec 172.16.8.5 -u='username' -p='Password@12345' --shares

I discovered that the share //172.16.9.69/DC2_Disk_Images was configured with excessive permissions, allowing any valid user on the domain to browse its contents.

I mounted the share using the compromised account and discovered a virtual hard disk file for the domain controller. To mount the file share, I used the mount utility:

#Create a mount point
mkdir /home/mrnobody/mount

#Mount the discovered file share
sudo mount -t cifs //172.16.9.69 /home/mrnobody/mount -o username=username,domain=domain.local

#To unmount the drive
sudo umount -a -t cifs -l

Inside this share sat the “keys to the kingdom”: a virtual hard disk (VHDX) file for the organisation’s Domain Controller.

From Disk Image to Local Admin

Having access to a VHDX file is effectively the same as having physical access to the server. I mounted the disk and extracted the SYSTEM, SAM, and SECURITY registry hives. Using secretsdump from Impacket, I was able to pull the local administrator’s password hash. For a full cheat sheet on secretsdump and other Impacket tools, click here.

The bonus with this method is that it is offline. This network was using SentinelOne endpoint protection on its servers and user workstations. Normally, EDR tools block simple attempts such as Netexec, LSA, and SAM dumps, but this method bypasses those restrictions as you are working with the files offline on your own system.

With the local administrator hash in hand, it was possible to use tools such as NetExec, evil-winrm and impacket-smbexec to pass the hash and obtain access to the domain controller. However, modern networks have several limitations on passing the hash, so I set out to highlight more issues linked to obtaining the hash. In this case, the local administrator hash was easily crackable and reused across the environment, which are two separate findings on their own.

I used John the Ripper to crack the NT hash of the local administrator account. For a comprehensive cheat sheet on using John the Ripper, click here.

john hashes.txt --format-NT --wordlist=/home/mrnobody/hacking/CustomPasswords/common_custom.txt --fork=4 --rules=ALL

Now logged into the Hyper-V host as an administrator, I had a direct line to the running Domain Controller VM. I mounted the domain controller virtual disk in File Explorer and extracted the ntds.dit file along with the SYSTEM hive. This was the running domain controller, so it contained the up-to-date Active Directory objects for the domain. The ntds.dit is the database of Active Directory. With these files, I used secretsdump to extract the password hashes for every single user in the domain for offline cracking.

Using the secretsdump tool from impacket, I extracted all domain users’ hashes for offline cracking.

Final Objective: The Golden Ticket

To wrap up the compromise, I used the Domain Controller aesKey found within the ntds.dit to forge a Golden Ticket. This gave me persistent, undetectable Domain Administrator privileges that would survive even if the actual administrators changed their passwords. The ultimate takeaway here is that file share permissions are a security boundary. When we treat groups like “Domain Users” as a catch-all for access, we create a massive attack surface. In this example, any domain user is effectively a Domain Administrator with a few steps.

To create the Golden Ticket, I used the ticketer tool from Impacket. The command I used was:

impacket-ticketer -aesKey 93a659.......24da -domain-sid S-1-5-21-......147 -domain domain.local -user-id 5150 username_of_domain_admin

Important note: You have to have the RID and the name of a domain administrator who exists in the domain.

To use the ticket, I exported the ccache file. The export command in Linux is a shell built-in command used to make variables and functions available to subsequently executed child processes. To check that it is available, I used klist.

#Export ccache file
export KRB5CCNAME=username.ccache

#Check that it is available and valid
klist

With a valid Kerberos ticket, I used Netexec with the -k and –use-kcache to access the domain controller using the Golden Ticket.

Remediation

As you can see, a simple file share that is accessible to all domain users can pose a serious risk to the domain. To secure your environment, you must move away from using broad groups like Domain Users, Authenticated Users, or Everyone when configuring share and NTFS permissions. Instead, follow the Principle of Least Privilege (PoLP) by granting access only to specific departmental or administrative groups that strictly require it for their roles. Additionally, sensitive files such as VHD/VHDX disk images, backups, and configuration files should be moved to dedicated, hardened storage locations with strict access controls and auditing enabled to prevent unauthorised mounting or extraction of sensitive data like the NTDS.dit or registry hives.