Weak NTFS permissions can allow a number of different attacks within a target environment. This can include:

• Access to sensitive information
• Modification of system binaries and configuration files
• dll hijacking are things

These are things a penetration tester might typically consider. However, there are other opportunities that testers should be looking for, especially when we only have limited privileges and want to escalate or expand that access within an environment.

The following method is useful in an environment where privilege escalation or lateral movement is limited due to compensating controls. It is recommended that techniques such as password spraying and host assessment with tools like PowerUp be exhausted prior to use of this method.

With the limitations understood, what kind of access are we looking for within an environment? In this instance, we’re interested in the ability to write to locations where we might be able to get another user (or scanner) to execute content.

Typically, what we’ll be looking for are shares used for solutions such as roaming profiles, folder redirection, or users’ home directories. In the case of the former, administrators configure these solutions for ease of access, the ability to backup personal user content, and to support remote access and virtualization. Folder redirection can be configured using Group Policy. If you are unfamiliar, additional details can be found at the following URL: https://technet.microsoft.com/en-us/library/cc732275(v=ws.11).aspx

Similarly, roaming profiles can be set up within the user’s Active Directory account settings. A network share is usually identified where all of the user’s profile information (instead of individual folders) will be stored.

Again, for those who are unfamiliar, additional details can be found at the following URL: https://technet.microsoft.com/en-us/library/jj649079(v=ws.11).aspx

On the same dialog above, we can see the field to specify the user’s home folder. Typically, this is also a shared location. However, the home folder may not contain items that we’ll be targeting in the attack outlined below (shortcuts or internet favorites) but it is still a valuable location if we have write access.

So, how do we find these sensitive locations once we’re in an environment? The “Profile Path” and “Home Folder” properties can be interrogated by a standard user using the Get-UserProperties commandlet of PowerView as described in this blog post by HarmJ0y.

It is a bit more difficult to identify shared folders used to support folder redirection. In order to locate these folders, the SYSVOL share will have to be searched for the folder redirection policy. That is, unless the user account you’re using has folder redirection applied. In this case, you can inspect the INI files described in this article to determine folder redirection targets.

Once the target locations have been identified on the network, the Invoke-ShareFinder commandlet of PowerView or a similar tool can be used to determine where accessible folders exist (with the CheckShareAccess switch). Usage of Invoke-Sharefinder can be found at the following blog posts by HarmJ0y.

http://www.harmj0y.net/blog/powershell/veil-powerview-a-usage-guide/

https://www.veil-framework.com/hunting-sensitive-data-veil-framework/

Now that we’ve (hopefully) found writable locations, what kind of attacks can we execute? Some obvious ones include modification of commonly accessed files within the “My Documents” folder. This could include addition of a malicious macro such as a PowerShell Macro from unicorn.py.

Instead, we might backdoor an existing executable using a tool like msfvenom as described below.

https://www.offensive-security.com/metasploit-unleashed/backdooring-exe-files/

In both cases, we are hoping that a user executes the content resulting in an additional session and expanded access within the environment.

Instead of using one of these methods, we are going to explore a different option. This method involves the use of the Metasploit auxiliary/server/capture/smb module. This module is used to collect hashes for cracking via a malicious SMB server. Options for the module can be seen below.

This Metasploit module would be run on a host that the attacker controls. The IP address and port can be set via the SRVHOST and SRVPORT options respectively. In addition, the module can be configured to log the captured challenge response transaction in either a Cain&Abel or John the Ripper formatted output file for consumption by one of these two tools.

After setting options for the module, the attacker must execute the run command to start the server. The SMB server will then listen in the background and report when an smb hash is received and recorded to one of the specified output files. Execution of the module and display of the running job can be seen below.

Finally, the attacker can modify a shortcut or favorite within the writable directory to cause the user to make a connection and pass hashes to the waiting Metasploit module. As an example, checking the favorites of a user might reveal something like the one seen below.

The attacker replaces the correct URL (http://www.bing.com) with the attacker’s IP address and appropriate protocol (file://172.16.189.131/). Then, when the target user executes the selected shortcut or favorite, their computer automatically attempts to perform challenge response authentication with the server. Metasploit displays these attempts at the console and logs them to the specified output file. Capture output can be seen below:

The resulting hashes can then be transferred to a password cracker to recover the user’s credentials.

It should be noted that the modified shortcut will no longer work properly. However, this is likely to be ignored by the end user. In addition, the modified file may catch credentials from a scheduled scanner performing an authenticated vulnerability scan. The scanning account is likely to have administrator privileges which could result in quick success if a strong password is not used.