Disclaimer: This post is for educational and defensive security purposes only. Never
use the information and techniques shown here for anything illegal or on systems where you don’t
have explicit permission. Doing so could break the law and get you into serious trouble.
Summary
This entry in our SecCore Essential series highlights places were sensitive information may be stored and acquired by attackers. It is considered implemented if the following conditions are met:
- Passwords are stored in secure password managers
- Regular reviews of file shares, document storage and Active Directory attributes are conducted
- No initial passwords are used (e.g. in PXE Boot environments or new users)
- PXE Boot environments are secured using a strong password
Introduction
Sensitive information such as passwords or administrative manuals have to be protected from unauthorized use. Attackers or even low-privileged employees may be able to access data that should not be known to them if file shares, cloud storage containers or even some Active Directory attributes are forgotten or misconfigured.
Common Attack Vectors
This chapter is about places where such information can be commonly found.
File Shares
In on premise environments, file shares using protocols such as Server Message Block (SMB)1 or Network File System (NFS)2 are common and widely used by users and systems such as Active Directory for accessing and distributing files. However, this ease of use can cause users to inadvertently share files or entire partitions with the entire network. Shares can be configured with Access Control Lists (ACLs) to restrict access to their content, but these have to be configured correctly in order to keep data secure.
Not only new file shares can be problematic, existing (global) shares also invite users to upload documents that they need to share with colleagues, unaware that these documents can be read by any user on the network.
Common problematic files and their location include:
- Scripts with credentials in the SYSVOL and NETLOGON shares of an Active Directory domain
- Backups and SQL dumps in backup shares on database servers
- Configuration files for embedded systems on unsecured NFS shares
- Since many embedded devices can not be joined to an Active Directory, their NFS shares are commonly set to "public"
- Whole partition (C:, D:\ etc.) shares on clients or servers
- Web server configuration and backend code in www or httpd etc. shares
Cloud Storage
Cloud-only or hybrid environments tend to use cloud storage like SharePoint3, Nextcloud4 or OneDrive for data storage. These systems are usually more secure for sharing files, since restricting access to them is more intuitive for users. However, they also introduce some new problems and attack vectors. Many cloud services offer global full-text search, that often also includes text on images (via OCR). This makes it extremely easy for an attacker to gather information from a compromised user account, since they can natively search for phrases like "password" or "credential" in all accessible documents.
Active Directory Attributes
Active Directory attributes are fields for users, computers or groups that can contain additional information such as when the password was last set, a description of the asset or what their telephone number is. The following attributes for example can contain password information for users:
- unicodePwd
- userPassword
- unixUserPassword
- msSFU30Password
These attributes should never be readable by a low privileged domain user and regular audits for these attributes are recommended.
Additionally, a common security problem concerns a user's "description" attribute. Although this can be read by any user in the domain, it is often misused for storing sensitive information, such as initial passwords.
PXE Boot & Autopilot Rollout
Both PXE Boot and Windows Autopilot can be used to automatically set up devices such as laptops or workstation. PXE Boot is used in on-premise environments and uses TFTP to provide pre-configured system images to clients. These images can be encrypted using a password to protect possible secrets. However, tools exist5 to extract a password hash from the PXE environment that makes it possible to use a brute-force attack to crack the password locally. With this password the image can be downloaded and/or booted directly. This environment can then be searched for sensitive information such as a local administrator password or Wi-Fi credentials.
Autopilot on the other hand does not need any server hardware or system images. It is used to configure an already installed Microsoft Windows system. However, during the installation procedure (Out-Of-Box-Experience), it is possible to use the key combination Shift-F10 to open a command prompt window and search for sensitive information or create a new local administrator user that can be used for additional information gathering when the system has been set up completely.
Attack Scenario
This section should demonstrate how attackers abuse sensitive information to gain unauthorized access. The setup of this attack scenario is as follows:
- The attacker has a foothold in the internal network without user credentials
- The attacker has no considerations regarding OPSEC, the most straightforward approach is used
Since the attacker has already a foothold in the internal network, they can start searching for accessible file shares using tools such as NetExec6 with the following command:
nxc nfs <ip-range> --shares
This may find an accessible share such as the devshare$:
Because this share is accessible without authentication, they can start searching for sensitive files using NetExec:
Using NXC again, the accessible files can be downloaded and searched for sensitive information:
The downloaded file revealed Active Directory credentials, which can be used to log on to the domain and further enumerate the network:
Through the new access, other shares can be enumerated. Unfortunately, the financeshare is not accessible by the account test.lab.local, as it can be seen in the screenshot above. However, the access can also be used to read out the Active Directory attributes of all users:
As it can be seen, the user financeAccount@lab.local has a description that contains the password. This password can now be used to log on to the financeshare:
Using smbclient7, the share can be enumerated and sensitive files can be downloaded:

Mitigation
After fixing the share permissions, the devshare$ is not accessible anymore:
However, the user description also needs to be fixed. After removing the password from the description, it is not possible anymore to log on to the financeshare.