RDP logs and incident response

What is RDP?

Remote desktop protocol (RDP) is designed by Microsoft for remote management of Windows-based virtual desktops. It provides users a graphical interface to connect over the network to a remote computer. Having a remote access feature leaves the door open for attackers.

I’ll use this post to summarise some of the information and commands that I use when investigating an RDP incident.

Note that RDP connections are usually done via tcp/3389.

Installing Remote access for Windows server

Investigating RDP goes best in your own lab environment. This short section describes how you can quickly configure a Windows server with RDP.

You can download an evaluation version of Windows Server (both 2012 and 2016) for testing purposes. Download the ISO and configure a virtual machine with enough memory and disk space.

You do not have to enable the full Remote Desktop Services (RDS) role in Windows Server once the system has been installed. You only need to enable remote access. To do this open the Server Manager and navigate to Local Server. In the right pane you’ll then see Remote Desktop. This is disabled by default.

Click on the status disabled to enable it. This will open a dialog box where you can choose to Allow remote connections, with a warning dialog box. You can then add additional users that are allowed to have remote access. Note that the local administrator account or any member of the Administrators group is added automatically.


Forensic information gathering for RDP

Get all listening network connections, together with the process ID. Look for the PID (in this case 2984) that corresponds with the process listening on tcp/3389.

netstat -noa

List all running processes. Search for the corresponding PID from netstat.

Note that having an established network connection to the RPD port does not mean that there’s an established RDP session. The network connection indicates that the connection is established to, for example, present the login dialog box, it does not indicate a successful authentication. Because of the RDP brute fore scanners you’ll see lots of established network connection on un-firewalled RDP hosts that are connected to the Internet.

tasklist -v

Check if the process is started from outside system32 or not.

wmic process where "ProcessID=2984" get ExecutablePath

List the service details, via command line or via the Task Manager

tasklist /svc



Create a hash of the service host and verify with Virustotal.

Get-FileHash C:\Windows\System32\svchost.exe -Algorithm sha256

List the loaded DLLs.

Listdlls.exe 2984

Verify that the firewall is configured. First audit which profile is active. Also dump the other installed firewall rules (maybe there’s a custom rule inserted).

netsh advfirewall show currentprofile
netsh advfirewall firewall show rule status=enabled name=all | select-string -pattern "(LocalPort.*3389)|(LocalPort.*Any)" -context 9,4
netsh advfirewall firewall show rule status=enabled name=all

Get information on running RDP sessions.

Session shadowing

I will not cover a feature that’s called Session Shadowing. By using Session Shadowing you can observe the actions taken via RDP. It’s the same as sitting next to the user (possibly the attacker) who is using the RDP-client. In most environments, except when there is a specific GPO setting applied that disables the necessity for a user’s consent, session shadowing requires the confirmation of the user who started the RDP session. It’s unlikely an attacker will provide this confirmation.

Additionally Session Shadowing only works properly for live sessions, not afterwards when doing an investigation.

Command list

List the currently logged in users.

quser

Get an overview of active Remote Desktop sessions

qwinsta

List the processes running via Remote Desktop sessions.

qprocess

RDP log information

Disclaimer : information primarily gathered via Windows RDP-Related Event Logs: Identification, Tracking, and Investigation

Network logs

  • Microsoft-Windows-Terminal-Services-RemoteConnectionManager
  • Event 1149
  • A successful RDP client network connection but does not indicate a successful authentication (despite what the log event has as description).

System authentication

  • Microsoft-Windows-Security-Auditing
  • Event 4624 + LogonType : 10 or 7
  • Successful authentication with an account
  • Event 4625
  • Failed authentication

RDP Session

  • Microsoft-Windows-TerminalServices-LocalSessionManager
  • Event 21
  • Successful RDP logon and session start. Often preceded by an event 22.
  • Event 22
  • Successful RDP logon and shell start. Often followed by an event 22.
  • Event 24
  • The user has disconnected from an RDP session
  • Event 25
  • The user has reconnected to an existing RDP session
  • Event 39
  • The user formally disconnected from the RDP session.
  • Event 40
  • The user disconnected from or reconnected to an RDP session
  • Event 23
  • The user initiated a formal system logoff (versus a simple session disconnect)
  • Microsoft-Windows-Security-Auditing
  • Event 4778
  • The user reconnected to an existing RDP session. Often paired with ID 25.
  • Event 4779
  • The user disconnected from from an RDP session. Often paired with ID 24, likely also 39 and 40.
  • Event 4634
  • A user disconnected from, or logged off, an RDP session.
  • Event 4647
  • The user initiated a formal logoff (NOT a simple disconnect).
  • Microsoft-Windows-System
  • Event 9009
  • A user has closed out an RDP connection.

One thought on “RDP logs and incident response

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.