A hacker who possesses domain user rights on an internal network can then attempt to acquire additional rights. In many cases, this does not require any additional software or even a zero-day exploit; the hacker just needs intuition and a bit of patience. In a company environment, hackers will usually find plenty of available shares containing access credentials, technical details and sensitive information, such as personnel or customer data.

Rights escalation made easy

Files like unattend.xml and Groups.xml are preferred targets. The file unattend.xml is used for the unattended installation of Windows systems. The access credentials required for local administrator accounts to run installations or domain users to connect a certain system with the domain are kept in this file. Passwords are either saved in plaintext or encoded in Base64.

The file Groups.xml is part of a group policy, which sets up a task and contains the login details of the relevant user, for example. In this case, the password is encrypted, but the same AES key is always used.

Batch, PowerShell and VB scripts as well as configuration files are additional ways to get one’s hands on access credentials. A hacker can browse shares manually or automatically to find these files. The login details that are discovered then make it possible for the hacker to gain additional rights and access other systems in the domain.

Minimizing the risk

Although these examples are hardly breaking news, we continue to find access credentials saved in these files when we carry out internal assessments. Granted, with a large number of Windows servers, completely preventing this is no small undertaking – particularly when the shares are not managed centrally. What needs to be done in order to minimize this security risk?

Regular checks

The first step is to take stock of the situation. In order to even monitor shares, one has to know of their existence. Here an IT department can use the same methods as a hacker would and regularly monitor the entire domain for open shares and the data they contain. The results from the check should then be analysed, documented and subsequently discussed with the person responsible for managing the application in question.

After that, any necessary measures can be taken, such as restricting access rights or removing the share. Shares should only be made available to users who actually need access to the provided information. Here it is important to note that administrators do not necessarily need to have access to these shares. If specific action is required, an administrator can grant themselves the necessary rights in order to do so.

When creating scripts and configuration files, it is important that passwords are never stored in plaintext. Passwords are either entered at runtime or saved in encrypted form. If access credentials are discovered when browsing for shares, these should be changed and the accounts in question monitored. After the password has been changed, any abuse can be discovered as soon as a person tries to log in using the old credentials.

Technical methods

In addition to the shares, the server configuration should be checked as well. The old SMBv1 protocol is not secure and must be disabled on all systems. Microsoft explains how to disable SMBv1 in a support article. Before disabling SMBv1, however, all systems should be checked to make sure they support SMBv2 and SMBv3. Ned Pyle, Principal Program Manager for Microsoft Windows Server High Availability and Storage Group, keeps a running list of manufacturers and products that still require SMBv1: SMB1 Product Clearinghouse.

The UNC Hardened Access function makes it possible to define security requirements for shares or servers. The UNC Hardened Access settings can be defined using group policies for the entire server \\<server> or individual shares \\<server>\<share>. Here there are various security settings, depending on the security requirements for the information stored in the share. There are currently three security settings that can be configured:

• RequireMutualAuthentication: The identity of the server and client must be mutually authenticated in order to block spoofing attacks.
• RequireIntegrity: Communication between the server and client passes an integrity check to detect and prevent the manipulation of the data traffic.
• RequirePrivacy: Communication between client and server must be encrypted so that sensitive information cannot be intercepted by third parties.

The Server Message Block (SMB) protocol cannot carry out mutual authentication on its own and therefore delegates this task to the security support provider of the operating system. If the security support provider cannot carry out verification successfully, the SMB client blocks access to the share. Mutual authentication is only possible if domain access credentials are used via Kerberos authentication; NTLM authentication is not supported.

To ensure integrity, SMB enables the SMB signing for I/O requests function. If the signing of SMB communication cannot be enabled, access is blocked in this case, too. Ideally, the server and client are configured with the default setting to always use SMB signing.

In Windows 8/Windows Server 2012 and later, the SMB client supports the SMB encryption for I/O requests function, which is used to meet privacy requirements. SMB clients that do not support SMB encryption will not be able to connect to the respective share.

Microsoft recommends enabling the security settings RequireMutualAuthentication and RequireIntegrity for the NETLOGON und SYSVOL shares. This also makes it possible to protect Group Policy objects against spoofing and tampering attacks. To ensure security, additional shares should also be protected with UNC Hardened Access whenever possible.

Monitoring and honeypots

In addition to regular checks and technical methods, further precautions should be taken as well. Access to file servers and shares should be monitored and analysed. An alarm should be triggered whenever a specific number of access attempts is made. The logs on the file server can also be scanned for failed access attempts resulting from insufficient rights. These logs show when an attempt is made to access existing shares and help determine whether the respective user possesses the required authorization.

Another possibility is to create honeypots to catch potential attackers. This involves storing files posing to contain legitimate login details at exposed locations. Scripts with access credentials can be saved in transfer directories, for instance. Or a Group Policy is created containing the supposed AD credentials. Access to these files and the credentials themselves are then monitored. As soon as someone attempts to log into the system with these credentials, an alarm is triggered, enabling the early detection of attacks in the information retrieval phase.

Conclusion

Open shares on a network create a risk of exposing sensitive data, such as login details. Through the measures described above, however, the risk can be reduced and better controlled. Monitoring access attempts and placing honeypots are additional ways to detect internal attacks. In this way, a common flaw can also be turned into an advantage when it comes to protecting the IT infrastructure – much like PowerShell Monitoring.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://blogs.technet.microsoft.com/filecab/2017/06/01/smb1-product-clearinghouse/
• https://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx
• https://support.microsoft.com/en-us/help/2696547/how-to-detect-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and
• https://support.microsoft.com/en-us/help/3000483/ms15-011-vulnerability-in-group-policy-could-allow-remote-code-executi
• https://twitter.com/nerdpyle