Remote Desktop Connections, Terminal Services and Plaso

tl;dr 

• Check the Microsoft-Windows-TerminalServices-LocalSessionManager and Microsoft-Windows-TerminalServices-RemoteConnectionManager logs for events relating to user logon/logoff. 
• Terminal Services events are logged for users that are accessing the machine locally. 
• You should require Network Level Authentication for RDP access to all your Windows machines to stop intruders using the “Sticky Keys” technique to retain access to machines. 
• Intruders can leak usernames and domains from their internal network and other victims in Microsoft-Windows-TerminalServices-RemoteConnectionManager ID 1149 events. 

Introduction

Tracking user logons and logoffs in intrusion investigations can be a pain. On Windows, the Security event log can get full pretty quickly, pushing out the 4624 and 4634 events that we usually use to to track this sort of activity. Thankfully, there’s some additional events in the Terminal Services logs that can provide a record of when users have logged into and out of.

The events we’re interested in are stored in %SYSTEMROOT%/System32/config/winevt/Logs/Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx and %SYSTEMROOT%/System32/winevt/Logs/Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx.

Compared to the Security log, there are many fewer events logged to these files, so they wrap much less frequently, providing information about events that happened further back in the past. A couple of caveats before we delve into these files a little more:

• These events are probably not logged on “Home” editions of Windows, as these don’t include Terminal Services/Remote Desktop functionality. I haven’t tested these variants of Windows though as they’re fairly uncommon in intrusion investigations of companies and organizations. 
• I haven’t tested all combinations of OS’s and Terminal Services/Remote Desktop settings. There’s likely to be situations where the events discussed below aren’t logged.

Ok, now on to the logs.

Terminal Services Remote Connection Manager

Events in this log relate to RDP client connections, and there’s one event of particular interest, event 1149.

Microsoft-Windows-TerminalServices-RemoteConnectionManager: Event 1149 

Here’s an example of a 1149 event from the Remote Connection Manager log, courtesy of Plaso/Psort:
Content Modification Time,EVT,WinEVTX,[1149 / 0x0000047d] Record Number: 134394 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-RemoteConnectionManager Computer Name: anadirws.ad.greendale.edu Strings: [u'pelton_da' u'AD' u'10.0.2.5']
According to Technet this event records a “successful user authentication”, and the three strings are:

1. User 
2. Domain 
3. Source address 

Testing Windows 7 and 2008 R2 with various RDP clients (rdesktop, Microsoft’s mstsc.exe, and the RDP module of ncrack) showed that the user and domain fields can be manipulated, so long as Terminal Services is not configured to require Network Level Authentication (NLA). In most configurations, NLA connections are available, but not required.
For non-NLA logins, Windows seems to grab the mstshash value from the RDP cookie and then put it directly into the log as the username.
I haven’t researched the RDP protocol deeply enough to confirm where in the exchange the domain is passed from the client to the server (maybe in the TS_INFO_PACKET?), but Windows doesn’t seem to validate it either, for non-NLA connections. There’s more scope for research here, to confirm that it’s actually the RDP cookie being logged here, and where the domain is passed.
I haven't found a straightforward way to tell whether a given 1149 event is associated with an NLA or non-NLA session. The best technique I’ve found so far is to look at the time elapsed time between a 1149 event and an Local Session Manager id 21 event (described below) and take an educated guess (a long gap means there’s manual intervention at the login screen, which means a non-NLA session).

Terminal Services Local Session Manager 

Events in this file relate to Terminal Services/Remote Desktop events that have taken place after an RDP connection has been successfully established. Events with IDs 21 through 24 in this log are particularly interesting.

Microsoft-Windows-TerminalServices-LocalSessionManager: Event 21

 Here’s an example event 21 from the Local Session Manager log:
Content Modification Time,EVT,WinEVTX,[21 / 0x00000015] Record Number: 5 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-LocalSessionManager Computer Name: PC1 Strings: [u'PC1\\ABED' u'1' u'LOCAL'] 

 According to Technet this event indicates a Remote Desktop session logon succeeding, and the three fields are:

1. User 
2. Session ID 
3. Source Network Address

The ‘LOCAL’ in our example event doesn’t look much like a network address though. In practice event ID 21 events seem to be recorded for all interactive logins, even non-Terminal Services logins. For console logins, the source address is recorded as “LOCAL”, as in the example. Also note that the ‘User’ fields contains the domain that the user is in, as well. A remote Terminal Service login looks pretty much as you’d expect, with the IP address of the connection logged by the server:

Content Modification Time,EVT,WinEVTX,[21 / 0x00000015] Record Number: 38 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-LocalSessionManager Computer Name: anadirws.ad.greendale.edu Strings: [u'AD\\pelton_da' u'2' u'10.0.2.5'] 

Microsoft-Windows-TerminalServices-LocalSessionManager: Event 22 

Here’s an example event id 22 event, from the Local Session Manager log:
Content Modification Time,EVT,WinEVTX,[22 / 0x00000016] Record Number: 15 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-LocalSessionManager Computer Name: TBARNESWS.ad.greendale.edu Strings: [u'AD\\tbarnes' u'1' u'LOCAL']

Technet states that this is Remote Desktop Services reporting the shell starting, and the fields are identical to Event 21:

1. User 
2. Session ID 
3. Source network address 

As was the case with Event 21, this event is recorded for local console logins too, with the Source network address being recorded as “LOCAL”.

Microsoft-Windows-TerminalServices-LocalSessionManager: Events 23 and 24 

The events with ID 23 and 24 are logged when a user logs out, or the session disconnects for some other reason. These are as described on Technet, and the User and Session IDs match up to the ID 21 and 22 events logged at session startup, which is useful for correlation.

Plaso support

Plaso has had tagging support for these events for a while now, via plasm and the Windows tag definition file. Terminal Services logon and logoff events can be tagged using plasm and filtered on using psort to get a quick overview of which users have been logging into a machine, when and where from.

If you’re not already tagging your Plaso storage files with plasm, I recommend incorporating it into your process. Starting with high interest tagged events can be particularly time-efficient way to focus your analysis. Tagging is as easy as:

plasm.py tag --tagfile=/path/to/tag_windows.txt storage_file.plaso 

and then you can search the storage file for tags like so:

psort.py storage_file.plaso "tag contains 'Application Execution'"

Timesketch

Describing these things is fine, but we can do better, and take a look at some actual (well, actual-ish) data - Timesketch is a (freshly updated!) collaborative forensic timeline analysis tool, and gives us a handy way to explore Terminal Services events. Timesketch uses ElasticSearch as a backend, and queries use the ElasticSearch query language.

Searching for event_identifier:1149 will show a (suspiciously?) large number of connections to one of the machines, and searching for event_identifier:21 AND source_name:"Microsoft-Windows-TerminalServices-LocalSessionManager" will show a bunch of local authentications, and a small number of sessions starts originating from the network.

One other search you should try is event_identifier:1149 AND NOT pelton_da. You can see here a connection from a user that doesn’t exist on the machine logging the event. Despite what the technet article might say, event id 1149 events do not necessarily indicate the successful authentication of a user, but rather a successful RDP session setup.

Sticky Keys

A brief aside on a technique used by intruders to get/maintain access to machines accessible over RDP. By either:

• replacing the stickykeys binary, sethc.exe; or 
• setting a shell or malicious binary as a debugger for the stickykeys binary 

Intruders can get a shell as the ‘SYSTEM’ user any time they’re presented with the Windows login screen, including the login screen presented on a remote desktop.
As has been documented elsewhere, NLA can cause problems for an intruder trying to employ this technique, but there are various ways to get around NLA being enforced on the server.

Observed mstsc.exe behaviour

mstsc.exe is the default utility on modern Windows systems for connecting to remote desktops. The following paragraphs outline the observed behavior of mstsc.exe (hereafter mstsc) on various variants and versions of Windows.

Windows 7 mstsc with NLA enabled

On Windows 7 mstsc will always attempt do an NLA login, and prompts the user for username and password before fully establishing a Terminal Services connection, and triggering the logging of a 1149 event. This is the NLA credential prompt:

If valid credentials are entered, 1149, 21, and 22 events will be logged with consistent usernames and domains. If the credentials are invalid, there will be a single 1149 event.
One other thing to note here is that using mstsc like this loads directly to the desktop, with no login screen from the Remote Desktop server being displayed. This means that there’s no opportunity to launch sticky keys, and regain access to a previously owned machine that way.

Windows 7 mstsc with NLA disabled 

On Windows 7 (and other contemporary versions of Windows) it’s possible to disable NLA in mstsc (remember, this is client side), either globally by editing %USERPROFILE%/Documents/Default.rdp or by creating a separate .rdp file and using that to make a connection. The magic line to add is “enablecredSSPsupport:i:0:1”.
When NLA is disabled mstsc will send in the RDP cookie the last username and domain that was successfully used to connect to the target server, and as we learned earlier, Windows will write these values to an Event Log entry with ID 1149..

This previous username value is stored in the Registry at HKCU\Software\Microsoft\Terminal Server Client\Servers\\(Values)\UsernameHint. The mstsc user will then be prompted with a login screen generated by the server, and be able to launch sticky keys or enter credentials for any user.
This means that if mstsc is used to connect to a hostname or IP address that has been previously accessed and NLA is disabled in the client, a 1149 event will be logged that contains the username and domain used in that previous connection, even if the mstsc user subsequently logs in as a different user at the login screen. This can lead to interesting clusters of events, like the following:

2014-08-03T13:05:06.146471+00:00,Content Modification Time,EVT,WinEVTX,[1149 / 0x0000047d] Record Number: 134398 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-RemoteConnectionManager Computer Name: anadirws.ad.greendale.edu Strings: [u'administrator' u'VICTIM1' u'10.0.2.5'],winevtx,TSK:/Windows/System32/winevt/Logs/Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx 
2014-08-03T13:05:30.677721+00:00,Content Modification Time,EVT,WinEVTX,[21 / 0x00000015] Record Number: 44 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-LocalSessionManager Computer Name:anadirws.ad.greendale.edu Strings: [u'AD\\pelton_da' u'2' u'10.0.2.5'],winevtx,TSK:/Windows/System32/winevt/Logs/Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx 
2014-08-03T13:05:30.724596+00:00,Content Modification Time,EVT,WinEVTX,[22 / 0x00000016] Record Number: 45 Event Level: 4 Source Name: Microsoft-Windows-TerminalServices-LocalSessionManager Computer Name:anadirws.ad.greendale.edu Strings: [u'AD\\pelton_da' u'2' u'10.0.2.5'],winevtx,TSK:/Windows/System32/winevt/Logs/Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx,-,2,224354
As you can see the user values for the Remote and Local Terminal services log entries do not match.

Information Leakage

Interestingly, if intruders aren’t careful they can leak the identity of other machines they’ve been accessing using mstsc.exe in ID 1149 events. This could happen if intruders are using some sort of tunnelling technique or VPN, and connecting repeatedly to the same IP address. Perhaps you should check your logs and see what domains are appearing in ID 1149 events.