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 Examples
As 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:
|RemoteDesktopServices-RDPCoreTS /Operational||98, 131|
|TerminalServices-LocalSessionManager/Operational||21, 22, 25|
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 Machine
Let’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.
In 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.
- The Subject section is the account logged into the source PC.
- The Account Whose Credentials Were Used section is self-explanatory: that is the account used when authenticating with the RDP Client to connect the remote machine.
- Target Server is the machine being connected to.
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 1102
For 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 Machine
The 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 4625
To 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.
Now, 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 131
Next, 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.
Lastly, 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.
Our 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.
The 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.
The 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.
First, 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.
- Code 0 means that there is simply no additional information available for the disconnection.
- Code 2 is similar to code 11; it is logged when an administrative tool was used to disconnect the session from another session.
- Code 5 is registered when a user connects to the machine, forcing the disconnection of another current connection. It could be the same username used or that the system simply does not support multiple concurrent sessions.
- Code 11 is registered when the disconnection was initiated by the user being disconnected from the session. This could be the user closing the RDP window or an administrative tool being used from the same session to force the disconnection, such as the logoff command in CMD or a batch file.
- Code 12 is registered when the disconnection was initiated by the user logging off their session on the machine, such as logging out via the start menu.
Finally, 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 Means
With 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.