In this post I am going to mess around with using an open-source tool for Linux called FreeRDP to gather information from a Windows machine running Remote Desktop Protocol (RDP) that may assist in an Incident Response scenario.
In the field of Incident Response (IR), time is almost never on your side. Whether a client has been hit by a destructive virus or traditional ransomware, it is the job of the responder to identify the threat, contain and eradicate it if possible as well as piece together how the system was compromised in the first place.
Ideally, the responder will want to go on-site to the client wherever possible and as quickly as possible, wherein they will usually bring with them a kit of ‘essential’ items. However, sometimes it is not feasible or even possible to go to the client directly for a variety of reasons. Luckily there are alternative options available to the responders.
It should be noted that RDP servers do exist for most major operating systems; however I have only tested the usage of this tool where the target machine is running Windows. Also, RDP servers are built into Windows by default and I would reasonably assume that a client in need of an Incident Response team for would have RDP open on their affected Windows machines over port 3389.
FreeRDP is conveniently provided on the latest full Kali Linux distribution and I will be running it as the host platform in a virtual machine using VMware Workstation 12. The mock IR client machine will be another virtual machine running Windows 10 alongside Kali.
The command to use FreeRDP in Kali is called ‘xfreerdp’ and as with any command in Linux, I highly recommend you read the man page before using it, as there are a wealth of options available. A portion of which can be seen as follows:
FreeRDP – A Free Remote Desktop Protocol Implementation
See www.freerdp.com for more information
Usage: xfreerdp [file] [options] [/v:<server>[:port]]
/flag (enables flag)
/option:<value> (specifies option with value)
+toggle -toggle (enables or disables toggle, where ‘/’ is a synonym of ‘+’)
/v:<server>[:port] Server hostname
/port:<number> Server port
/size:<width>x<height> Screen size
/f Fullscreen mode
/bpp:<depth> Session bpp (color depth)
/kbd:0x<layout id> or <layout name> Keyboard layout
/kbd-list List keyboard layouts
/kbd-type:<type id> Keyboard type
/kbd-subtype:<subtype id> Keyboard subtype
/kbd-fn-key:<function key count> Keyboard function key count
/admin Admin (or console) session
/multimon Use multiple monitors
/workarea Use available work area
/monitors:<0,1,2…> Select monitors to use
/monitor-list List detected monitors
xfreerdp connection.rdp /p:Pwd123! /f
xfreerdp /u:CONTOSO\JohnDoe /p:Pwd123! /v:rdp.contoso.com
xfreerdp /u:JohnDoe /p:Pwd123! /w:1366 /h:768 /v:192.168.1.100:4489
xfreerdp /u:JohnDoe /p:Pwd123! /vmconnect:C824F53E-95D2-46C6-9A18-23A5BB403532 /v:192.168.1.100
Clipboard Redirection: +clipboard
Drive Redirection: /drive:home,/home/user
Smartcard Redirection: /smartcard:<device>
Printer Redirection: /printer:<device>,<driver>
Serial Port Redirection: /serial:<device>
Parallel Port Redirection: /parallel:<device>
Printer Redirection: /printer:<device>,<driver>
Audio Output Redirection: /sound:sys:alsa
Audio Input Redirection: /microphone:sys:alsa
Multimedia Redirection: /multimedia:sys:alsa
USB Device Redirection: /usb:id,dev:054c:0268
Because the mock IR Windows machine is on my local network, I will be using its internal IP address for the ‘server hostname’ parameter of ‘xfreerdp’ on Kali. In this case, the target machine has an IP address of ‘192.168.149.132’ and the user account I shall be connecting as is an administrator named ‘DFIR-Windows’.
It is very important that you have the credentials for an administrator account when connecting over RDP otherwise it will NOT work!
The full command I will be using on my Kali machine is as follows:
# xfreerdp /drive:Tools,/root/Tools /v:192.168.149.132 /u:DFIR-Windows /p
A breakdown and explanation of the parameters/options used within this command:
Redirects a local folder to the remote machine, in this case the ‘local folder’ path is /root/Tools and the ‘remote name’ is ‘Tools’. This will display a drive on the target machine called ‘Tools on Kali’ which will contain any files/directories within /root/Tools.
Specifies the IP address/hostname of our target machine.
The name of the user account you are logging in as on the target machine.
Prompts for the password of the user account you specify with the ‘/u:’ flag. It should be noted that you can supply the password within the argument (/p:<password>), but it is not recommended to have the password in plaintext for security reasons.
As shown above, we have a successful RDP connection to our target machine; now we need to be able to run some information-gathering programs. Since we have redirected a local folder from our Kali machine, we can simply add Windows executable programs to said folder, to then be run while connected over RDP. For testing purposes, I have added the EnCase Imager and Process Explorer executables to /root/Tools. These can be accessed on the target machine by navigating to the ‘Tools on Kali’ drive in Windows Explorer and then it is a simple matter of executing them just as you would any Windows program.
The below screenshot shows the ‘Process Explorer’ program being run on the target machine over RDP:
Using the EnCase executable, we can also dump the physical memory of the target machine directly to our redirected drive. To do this, simply open EnCase Imager, click ‘Add Local Device’ and then tick the option ‘Enable Physical Memory’ (You can also select ‘Enable Process Memory’ if you desire). Then tick the box next to ‘RAM’ and click ‘Finish’. Finally, select ‘RAM’ in the tree pane and then ‘Acquire’, you will then be prompted for details as shown in the screenshot below.
In this instance, I had assigned the Windows 10 target machine 2GB of RAM, which only took around 5 minutes to acquire and verify. The result was a memory dump file in the compressed Expert Witness format (Ex01) which can then later be analyzed with software of your choice.
I did not have time to test many other tools/methods, but it should be noted that I ran into some difficultly using Windows programs that came with library files. However, programs that are contained within a single Portable Executable (PE) file should work just fine. It is also possible to execute batch scripts that could gather volatile information such as the routing table, cache files, event log files, etc. (complying with RFC 3227) and write them to an output file on the shared drive (which has a pathname of \\tsclient\<name> where the name is the first parameter given in the ‘xfreerdp’ drive option).
Thank you for reading and I hope this information has taught you something new!
If you have any questions about this post, please email me using the form in the ‘Contact’ section at the top of the page.