1) Start the Windows Event Viewer after looking it up in the Start menu, typing 'Event Viewer', or as an alternative: 2) When the Event Viewer is open, select the View option from the command bar and enable the Show Analytic and Debug Logs option:  Note: If this option is already enabled, then a small tick icon will be present in line with the text. 3) In the navigation pane, on the left: Expand the Applications and Services Logs drop-down, then further expand it at Microsoft and under that at Windows. Note: With the 'Show Analytic and Debug Logs' option enabled from step 2), you will be able to see the following 3 terminal services: Microsoft-Windows-TerminalServices-RDPClient/Operational 5) Right click on the RDPClient/Debug terminal service and enable logging via the 'Enable Log' option, please proceed with the same on the RDPClient/Analytic terminal service, if logging is not enabled on that. 6) When all of the above set, please do not close the Event Viewer and open the Remote Desktop Connection app to reproduce the RDP connection to the target. 8) On the right side of the window, in the Actions pane, click on the 'Refresh' option: new events should appear under the selected service: 9) To save these new events to a file: after a right click on the selected terminal service in the navigation pane: the 'Save All Events As...' option will be present:
Important to note: Please use the above described method to save new events on all these three mentioned terminal services, then please provide the .evtx files for us as an attachment under the service request. Note: the previously enabled logging at step 5) can be disabled now, if no further reproductions will follow.
Investigating lateral movement activities involving remote desktop protocol (RDP) is a common aspect when responding to an incident where nefarious activities have occurred within a network. Perhaps the quickest and easiest way to do that is to check the RDP connection security event logs on machines known to have been compromised for events with ID 4624 or 4625 and with a type 10 logon. However, that is not at all always a surefire way to detect if such activity has occurred. It is becoming more and more common for bad actors to manipulate or clear the security event logs on compromised machines, and sometimes RDP sessions don’t even register as just a type 10 logon, depending on the circumstance. RDP activities, like most activities, will leave events in several different logs as action is taken and various processes are involved. Log Events and ExamplesAs digital forensic investigators, we need to find the evidence we’re interested in and ensure we are not overlooking information that could also be available in the event logs, even after standard security log wipes. Let’s consider the following logs and events:
This list is by no means all-inclusive—there are others too—but this example will give us a good cross-section of what these activities will leave for additional or supporting evidence. The Source MachineLet’s begin with the source machine. There will be less there to see here, but there are events created when using the RDP client to connect to another computer, which can be very important. These events help verify other logged events on the destination machines and can help identify other systems that may have been compromised. Event 4648In the security log, an event gets logged with ID 4648 whenever an authorization takes place using explicit credentials. When that authentication is used for a remote system it looks something like this: The important information we can get from this event are in the top three sections.
There are a few things to keep in mind when looking at 4648 events. First, they get logged a lot—whenever explicit credentials are used. Most of the time, they will show as targeting local host as credentials were used locally, or other systems if credentials are used to access or connect to resources. Second, which you’ve probably noticed, there is nothing in this event to signify that this authentication was for an RDP connection. That is exactly why it is important to correlate logs so that you can tie events from the destination machine to this time frame and verify the accuracy of the log. You can now be certain that this was the destination machine. Finally, pay attention to the subject and account name under Account Whose Credentials Were Used. If you see a known-compromised account using additional accounts, you can identify additional compromised accounts and possibly verify that other authentication attacks have occurred. You could also then browse all events with ID 4648 around the same time to see if there are any others that look like they could have been connections to other workstations, gaining more evidence of lateral movement. Events 1024 and 1102For the next two events, we’ll look at reside in the TerminalServices-RDPClient\Operational event log on the source machine. In the event viewer, you can find this log under Application and Services Logs \ Microsoft \ Windows \ TerminalServices-ClientActiveXCore. These events have the IDs 1024 and 1102, and each has a specific, potentially useful, piece of information. First, 1024 will usually appear in the logs a couple of seconds before our 4648 event from above. It shows us that the RDP client is attempting to connect to a remote machine or server. It will include the name of the machine, if it is available. Second, 1102 will usually appear about 10 seconds (give or take a few) after the 1024 event. It will provide us with the IP address of the remote machine once it has initiated a connection with the destination. Event 1102 likely won’t give us anything new, assuming we have identified the 4648 event from the security log. But, as I mentioned earlier, it is becoming more common for attackers to clear the security log in an attempt to cover their tracks. It is always useful—and often critical—to have multiple places where corroborating evidence can be found. Having the IP address from 1102 will also be useful, especially if a machine name is not available. Now, with that, let’s look at the destination machine. As this is the machine that the most activity is occurring on, we have quite a bit more to observe. The Destination MachineThe destination machine is the machine that has been remotely accessed. It (hopefully) has quite a few logs available to review. Most likely, if logs have been tampered with or cleared, this is the machine they’ll do it on. Events 4624 and 4625To start, let’s take a quick look at our old friends 4624 and 4625. Now, I am sure most folks reading this know what these events look like, but I want to point out something about the Logon Type as it relates to RDP activity. Here are two 4624 events. 4625 is, of course, just an authentication failure, meaning the username or password was wrong. But, the logon type is noteworthy. In the first, on 9/29/2020, we see the account of pgreenman log in with a logon type of 10. We know type 10 is for a remote interactive logon, which is what we would expect to see. We know type 10 is for a remote interactive logon, which is what we would expect to see. However, on the following day, we see the account log in with a logon type of 7. The connection was still an RDP connection, so why was it not logged as a Type 10? Type 7 logons are used for unlock events. Likely, what has happened is that pgreenman’s account was not fully logged off; only the interactive session had ended, and there is likely no timeout to end disconnected sessions set in GPO. So, when he reconnected the following day, instead of registering as a new RDP login (type 10) it registered simply as an unlock of the session (Type 7). This helps illustrate why it is important to keep in mind that we might not always see a type 10 logged for every RDP connection. There should, however, be one type 10 logon logged when the session is first initiated. However, that event could have been deleted. Or, the logs may have rolled over if there has been a session logged in for an extended time. Event 1149Now, let’s move on to some of the less commonly reviewed logs. Let’s look at event ID 1149 within the TerminalServices-RemoteConnectionManager/Operational log. Event 1149 is logged when there is a successful RDP logon to the computer. Before Windows 7 and Windows Server 2012, 1149 would be logged for any initiation of an RDP connection, so it was not a useful indicator for an actual successful application of user credentials. But, that has changed, and all modern OS versions will only log 1149 if the username in the event was successfully authenticated. It also includes the IP address of the source of the connection, which is useful information. If an account is used and successfully authenticates but does not have permission to RDP to the computer due to other restrictions, event 1149 is not generated. Events 98 and 131Next, let’s look at events 98 and 131 in the RemoteDesktopServices-RDPCoreTS /Operational log. With these two events, what we’re seeing is a record of the acceptance and establishment of the TCP connection for the RDP session. You’ll see several event 131s per 98. Some will be UDP and some TCP, as RDP can now utilize both. The evidence we have is still useful to note. Again, it is always good to be able to find corroborating evidence in several places. To reiterate: we can see the IP address the connection is coming from, and by looking at the event 131s, we can see what ports were being used as well. Other EventsLastly, for the events that generate at connection of the RDP session, let’s review at some event IDs within the TerminalServices-LocalSessionManager/Operational log. Here, the events we will look at are 21, 22, and 25. Each gets logged under a slightly different circumstance. Events 23 and 40 are others to note. We’ll cover those last, as they pertain to the logoff of the session. As the name of the log implies, these events all pertain to the management of local sessions by Terminal Services. Event 21Our first event, ID 21, is registered when RDP successfully logs into a session. The event will log both the connected username and the session ID number assigned. The username here includes the domain and is the account used to log in, not necessarily the account logged into the source machine. Event 22The next event to note is 22. This contains much of the same information as 21, so nothing really new there. But it is registering the reception of the Shell start notification, which can be additional evidence of the interactive logon session, aka graphical interface of windows which RDP provides. Event 25The last of the logon or connection events we’ll look at today is event 25. This event is logged when RDP is reconnecting to a session, like that type 7 logon we mentioned above. There was already a logged in session for the user, and then RDP reconnected to it. It could be that the session was local or a previous RDP session. Either way, we would have seen 4624 created with a type 7 logon. This event also includes the source IP address of the connection, which could be valuable if it was not available in the previously mentioned events. Now, as always, we need to consider the full timeline of activity that was carried out by the attacker on the systems we are investigating. So not only should we look for logon and connection events, but also logoff events. There are, of course, two events which will appear in the Security log, 4634 and 4647. These register the event when a user initiates a logoff (4647) and when the user is actually logged off (4634). You can glean some additional tidbits regarding whether the system was rebooted by comparing Logon IDs. For the most part, that is what they will tell you, and they don’t indicate if the session was local or remote. But, if your security logs are intact, they can be helpful in filling out our understanding of the actions the attacker has taken. However, as I have mentioned several times, the security log is a prime target for log manipulation and destruction, so we will want other places to gather this information. For that, we turn back to the TerminalServices-LocalSessionManager/Operational log and the two events I mentioned earlier: 23 and 40. Event 40First, let’s look at Event 40. This event is registered whenever a session is disconnected, so that could be an interruption or the user disconnecting or logging off. Within the event text, we are given a reason code, which gives us detail on the disconnection. Most often, you’ll see types 0, 5, 11, and 12, but there are definitions for all codes from 0 to 12.
Event 23Finally, we have Event 23, which is registered when the session is logged off successfully. This would be logged after any log off scripts or other tasks are scheduled to be completed at logoff, and it shows that the session has truly come to an end. It, again, registers the user who was connected and the session ID that was associated. What It All MeansWith that, we have seen the timeline of these connections. We’ve followed from the initiating events on the source machine to the end of the session on the destination. From the information within these events, we can piece together a timeline of when a computer was accessed, from where, and for how long, even if the session may have lasted over several days and other connections. Hopefully, taking the time to review these event IDs, what they can show, and how they relate will prove to be valuable when tracking down suspicious lateral movement. Or, maybe you just understand the event logs in relation to RDP a bit more. This article was written by Tim of Team Ambush This post is part of Team Ambush’s FRSecure Labs content. Check out their page to read more like it. |
