Archived Forums
>Remote Desktop Services [Terminal Services]
General discussion
-
0
Sign in to vote
I am experiencing an issue connection to an RDS farm from another machine. The client tries to connect then gets the generic error 'Remote Desktop can't connect to the remote computer for one of these reasons:' etc.
In the Microsoft-Windows-TerminalServices-RDPClient/Operational log I get the following message when the client does not connect:
Log Name: Microsoft-Windows-TerminalServices-RDPClient/Operational
Source: Microsoft-Windows-TerminalServices-ClientActiveXCore
Date: 6/9/2014 2:45:00 AM
Event ID: 226
Task Category: RDP State Transition
Level: Warning
Keywords:
User: WBC\cwestwateradmin
Computer: WBC-ITTS-01.wbc.local
Description:
RDPClient_TCP: An error was encountered when transitioning from TcpStateConnectingTransport to TcpStateDisconnected in response to 2 [error code 0x80004004].
Event Xml:
226
0
3
104
19
0x4000000000000000
12199
Microsoft-Windows-TerminalServices-RDPClient/Operational
WBC-ITTS-01.wbc.local
RDPClient_TCP
1
TcpStateConnectingTransport
11
TcpStateDisconnected
2
TcpEventConnectionTimeout
2147500036
It's an intermittent issue but I would say 80% of the time the connection fails.
Any help appreciated
- Changed type Dharmesh SMicrosoft employee Monday, July 7, 2014 8:26 AM
Monday, June 9, 2014 8:06 AM
-
0
Sign in to vote
Hi,
all check out. The farm is working fine for 300+ users, it just seems to be an intermittent issue on this computer.
Colin
Tuesday, June 10, 2014 5:03 PM
-
0
Sign in to vote
Hello, was MS able to help. I am having a similar, possibly the same issue.
Thanks,
Steve
Friday, July 4, 2014 1:57 PM
30 Replies
· · ·
Tabasco
OP
Aug 30, 2021 at 18:15 UTC
If that really says "RemtoeDesktopServices-RdpCoreTS" and not "RemoteDesktopServices-RdpCoreTS" I think I would start with a malware scan.
///
Otherwise, do the server and client both believe they are on the domain or private network [rather than public] profile?
- If not, have you tried restarting the Network Location Awareness service?
Have you tried connecting to the server from a different client?
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 18:21 UTC
nhnm wrote:
If that really says "RemtoeDesktopServices-RdpCoreTS" and not "RemoteDesktopServices-RdpCoreTS" I think I would start with a malware scan.
///
Otherwise, do the server and client both believe they are on the domain or private network [rather than public] profile?
- If not, have you tried restarting the Network Location Awareness service?
Have you tried connecting to the server from a different client?
No, just a typo since I didn't directly copy & paste.
The domain profile is active on both the servers and clients.
Restarting the NLA service didn't seem to change anything.
I have tried 3 different clients. 2 within the domain, and one outside of the domain [which was working previously].
0
· · ·
Habanero
OP
Aug 30, 2021 at 18:25 UTC
Windows Server expert
69 Best Answers
219 Helpful Votes
Can you telnet from the client to the server on port 3389 and open the port?
Open a cmd prompt and type telnet servername 3389 [if it works, it'll simply open a blank window]
Do you have any other servers? If so, can you try to RDP to the DC from there?
These are basic information gathering steps to see where to go from there.
1
· · ·
Tabasco
OP
Aug 30, 2021 at 18:28 UTC
Have you already tried restarting the Remote Desktop services on the server?
Have you checked the Remote settings in System Properties to make sure the configuration hasn't changed from what you expect [not sure if you have multiple people able to adjust those settings or not]?
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 18:31 UTC
jrp78 wrote:
Can you telnet from the client to the server on port 3389 and open the port?
Open a cmd prompt and type telnet servername 3389 [if it works, it'll simply open a blank window]
Do you have any other servers? If so, can you try to RDP to the DC from there?
These are basic information gathering steps to see where to go from there
Once I installed telnet on the client, I got this:
Text
could not open connection to the host, on port 3389: connect failedBut that seems odd. The firewall rules for RDP are active and should still be allowing RDP.
There are 2 domain controllers. Both are behaving the same way and not responding to RDP.
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 18:34 UTC
nhnm wrote:
Have you already tried restarting the Remote Desktop services on the server?
Have you checked the Remote settings in System Properties to make sure the configuration hasn't changed from what you expect [not sure if you have multiple people able to adjust those settings or not]?
No change after restarting the RDS service.
Yes, the remote settings haven't changed and there don't appear to be any surprises in there.
0
· · ·
Tabasco
OP
Aug 30, 2021 at 18:34 UTC
Can you run a netstat -a on the server and see what state 3389 is in?
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 18:38 UTC
nhnm wrote:
Can you run a netstat -a on the server and see what state 3389 is in?
Text
TCP 0.0.0.0:3389 myserver-1:0 LISTENING TCP [::]:3389 myserver-1:0 LISTENING UDP 0.0.0.0:3389 *|*0
· · ·
Habanero
OP
Aug 30, 2021 at 18:43 UTC
Windows Server expert
69 Best Answers
219 Helpful Votes
Try turning RDP off then back on. right click start menu > run > sysdm.cpl > Press enter > go to the remote tab > turn off RDP and hit apply > turn it back on and hit apply > test from client again
If that doesn't work, turn the firewall off completely for a moment to see if it works. That will tell you if it's firewall related[I know, even though you said nothing has changed]. The firewall can be tricky if a network adapter gets switched from any of the three possible network options to another and if a rule is only being applied to a certain network[s].
1
· · ·
Thai Pepper
OP
Aug 30, 2021 at 18:47 UTC
I can't turn RDP off manually--it's enforced by group policy and grayed out.
Turning off the firewall briefly allowed me to connect from a client. Interesting.
0
· · ·
Tabasco
OP
Aug 30, 2021 at 18:49 UTC
In your remote settings, is "Allow connections only from computers running Remote Desktop with Network Level Authentication" checked? Have you tried temporarily unchecking it to see if a connection is allowed?
If turning off the firewall briefly allowed a connection, maybe double check and / or recreate the RDP rule[s] in the firewall and see if they are set to apply to all of the desired profiles - domain, private, public.
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 18:53 UTC
Ok, so the firewall rules are not correct. There is a remote desktop rule, but it's a barebones rule with grayed out options and doesn't include anything that was configured from group policy. Very odd.
gpresult is not showing the same settings for the firewall rule as what is actually configured in group policy.
I've tried gpupdate /force and a reboot, but the correct settings don't seem to be popping up on the server.
The correct firewall settings to appear to be on the clients.
1
· · ·
· · ·
Tabasco
OP
Aug 30, 2021 at 19:01 UTC
You mentioned this in your OP:
"your windows domain controller cannot be contacted to perform NLA" - and also the piece about working with time settings.
...This together with the RDP / NLA issues could be time related for sure.
Could you run these commands on the server and a test client to see if the output is what you expect?
Text
w32tm /query /source w32tm /query /status w32tm /query /configuration0
· · ·
Habanero
OP
Aug 30, 2021 at 19:02 UTC
Windows Server expert
69 Best Answers
219 Helpful Votes
Change something about that firewall rule in group policy apply it then change it back and reapply it to see if that will tickle that record and make it trickle down do another GPupdate as well.
1
· · ·
Tabasco
OP
Aug 30, 2021 at 19:04 UTC
If something looks off, you could try to unregister / re-register the time service:
Text
net stop w32time w32tm /unregister w32tm /register net start w32timeAnd then try the above time queries and see if it changes to what you expect.
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 19:09 UTC
nhnm wrote:
You mentioned this in your OP:
"your windows domain controller cannot be contacted to perform NLA" - and also the piece about working with time settings.
...This together with the RDP / NLA issues could be time related for sure.
Could you run these commands on the server and a test client to see if the output is what you expect?
Text
w32tm /query /source w32tm /query /status w32tm /query /configuration
The reason I started fiddling with the NTP settings was that a client was throwing errors and the time wasn't actually syncing. I'm starting to think that may have thrown things off in group policy.
Text
w32tm /query /source VM IC Time Synchronization Provider w32tm /query /status Leap Indicator: 0[no warning] Stratum: 5 [secondary reference - syncd by [S]NTP] Precision: -23 [119.209ns per tick] Root Delay: 0.0001548s Root Dispersion: 0.0100002s ReferenceId: 0x564D5450 [source IP: 86.77.84.80] Last Successful Sync Time: 8/30/2021 3:03:23 PM Source: VM IC Time Synchronization Provider Poll Interval: 6 [64s] w32tm /query /configuration [Configuration] EventLogFlags: 2 [Local] AnnounceFlags: 10 [Local] TimeJumpAuditOffset: 28800 [Local] MinPollInterval: 6 [Local] MaxPollInterval: 10 [Local] MaxNegPhaseCorrection: 172800 [Local] MaxPosPhaseCorrection: 172800 [Local] MaxAllowedPhaseOffset: 300 [Local] FrequencyCorrectRate: 4 [Local] PollAdjustFactor: 5 [Local] LargePhaseOffset: 50000000 [Local] SpikeWatchPeriod: 900 [Local] LocalClockDispersion: 10 [Local] HoldPeriod: 5 [Local] PhaseCorrectRate: 7 [Local] UpdateInterval: 100 [Local] [TimeProviders] NtpClient [Local] DllName: C:\Windows\system32\w32time.dll [Local] Enabled: 1 [Local] InputProvider: 1 [Local] CrossSiteSyncFlags: 2 [Local] AllowNonstandardModeCombinations: 1 [Local] ResolvePeerBackoffMinutes: 15 [Local] ResolvePeerBackoffMaxTimes: 7 [Local] CompatibilityFlags: 2147483648 [Local] EventLogFlags: 1 [Local] LargeSampleSkew: 3 [Local] SpecialPollInterval: 1024 [Local] Type: NT5DS [Local] NtpServer [Local] DllName: C:\Windows\system32\w32time.dll [Local] Enabled: 1 [Local] InputProvider: 0 [Local] AllowNonstandardModeCombinations: 1 [Local] VMICTimeProvider [Local] DllName: C:\Windows\System32\vmictimeprovider.dll [Local] Enabled: 1 [Local] InputProvider: 1 [Local]0
· · ·
Habanero
OP
Aug 30, 2021 at 19:15 UTC
Windows Server expert
69 Best Answers
219 Helpful Votes
If modifying that rule doesn’t work. I would simply delete it and re-create it.
1
· · ·
Tabasco
OP
Aug 30, 2021 at 19:16 UTC
I see you're using VM time sync. Does the host OS have the correct time / time settings?
Is this an Azure VM? If so, have you taken a look at this:
//docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/cannot-connect-rdp-azure-vm
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 19:17 UTC
jrp78 wrote:
Change something about that firewall rule in group policy apply it then change it back and reapply it to see if that will tickle that record and make it trickle down do another GPupdate as well.
In the RDP rule, I added a new IP to the remote IP scope, did a gpupdate /force, did a reboot, but there was no change on RDP firewall rule on the server
0
· · ·
Thai Pepper
OP
Aug 30, 2021 at 19:18 UTC
nhnm wrote:
I see you're using VM time sync. Does the host OS have the correct time / time settings?
Is this an Azure VM? If so, have you taken a look at this:
//docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/cannot-connect-rdp-azure-vm
Yes, it has the correct time.
No, it is not Azure VM. Windows server hyper-v
0
· · ·
Habanero
OP
Aug 30, 2021 at 19:24 UTC
Windows Server expert
69 Best Answers
219 Helpful Votes
I made a comment above and I’m not sure you saw it but I said to try deleting and re-creating that rule.
1
· · ·
Thai Pepper
OP
Aug 30, 2021 at 19:35 UTC
jrp78 wrote:
If modifying that rule doesn’t work. I would simply delete it and re-create it.
I noticed other firewall rules are missing their settings as well as this RDP rule.
I'm thinking this is a larger issue than just one single firewall rule.
I deleted the rule and re-created it [and used a different name]. The old rule is still there, the new rule has not appeared [after gpupdate /force and reboot]
0
· · ·
Habanero
OP
Aug 30, 2021 at 19:51 UTC
Windows Server expert
69 Best Answers
219 Helpful Votes
Check the event viewer logs on the machine right after you try the gpupdate on it. Are you seeing an group policy related errors?
0
- 1
- 2
Oops, something's wrong below.
Text
-
-
-
Quote Post
|
Add link Text to display: Where should this link go?
Add Cancel
Insert code
Language Apache AppleScript Awk BASH Batchfile C C++ C# CSS ERB HTML Java JavaScript Lua ObjectiveC PHP Perl Text Powershell Python R Ruby Sass Scala SQL VB.net Vimscript XML YAML
Insert Cancel
Join me to this group
ReplyRDP: An Internal Error Has Occurred
In some cases, when connecting to remote computers/RDS servers via Remote Desktop [RDP], users may encounter an “An internal error has occurred” error. This error may appear due to various reasons related to both the settings of the RDP/RDS server and the client [Windows settings, or settings in the Remote Desktop Connection window].
The error “An internal error has occurred” usually appears after user credentials are entered in the mstsc.exe window or immediately after clicking the Connect button.
Since there may be several causes for this RDP error, try to use the following tips one by one until you find a solution that will help you.
The easiest way to fix the problem is to reboot the remote RDP/RDS host and the computer from which you are establishing an RDP connection. If you cannot restart the server right now, you should try to restart the Remote Desktop Service [together with the Remote Desktop Services UserMode Port Redirector]. You can do this with the following commands running in the elevated cmd.exe:
net stop termservice net start termserviceOr you can restart Remote Desktop Services from the services.msc console.
Reset the DNS client cache on your computer by running the following command from an elevated command prompt:
ipconfig /flushdnsIf you are using a VPN to connect to a remote network, try disabling the VPN connections and try reconnecting to the RDP host. You can find and disable all active native Windows VPN connections using PowerShell:
foreach [$item in get-vpnconnection | where { $_.ConnectionStatus -eq "Connected" }] { Rasdial $item.Name /disconnect }If you are using third-party VPN software, disconnect VPN sessions from its interface.
Open the properties of your RDP connection in Remote Desktop Connection windows and make sure the ‘Reconnect if the connection is dropped‘ option is enabled on the Experience tab.
Try to disable the Server Authentication warning in the Advanced tab of the RDC client. Set the If server authentication fails to Connect and don’t warn me.
Check the Security Event Log for the following event ID 5379:
Credential Manager credentials were read.
This event occurs when a user performs a read operation on stored credentials in Credential Manager.
Your RDP client may have tried to use saved credentials for RDP connections. You need to remove it from Credential Manager:
- Open Windows Credentials in Control Panel [or by running the command: rundll32.exe keymgr.dll,KRShowKeyMgr];
- Delete the saved RDP logon credentials for your remote host. Find the entry that starts with TERMSRV\your_rdp_host_name or TERMSRV\your_rdp_IP_address and click the Remove button;
Next, try to recreate the RDP certificate:
- Open local computer certificates MMC snap-in, by running the certlm.msc command;
- Go to the following certificate section: Remote Desktop > Certificates;
- Right-click your self-signed certificate RDP cert and delete it [if there are several RDP certs, remove them all];
- Restart the Remote Desktop Services as described above.
You can try to change the maximum outstanding connections limit on your RDP server via the registry. Set the following registry value via regedit.exe:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
DWORD: MaxOutstandingConnections
VALUE: 10000
Or with PowerShell:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" -Name MaxOutstandingConnections -Value 10000 -PropertyType DWORD -ForceCheck the current MTU size in your Windows with the command:
netsh interface ipv4 show subinterfacesIf the current MTU size for your network interface is equal to or more than 1500 [default Windows value], reduce it by using the command:
netsh interface ipv4 set subinterface "vEthernet [vSwithcExternal]" mtu=1452 store=persistentTry to change some Group Policy settings using the Local GPO editor [gpedit.msc] or domain Group Policy Management Console [gpmc.msc].
- Disable UDP protocol for RDP connection on client side: Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Turn Off UDP on Client = Enabled;
- Enable FIPS compliant algorithms: Computer configuration > Windows Settings > Security Settings > Local Policies > Security Options > System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing = Enabled;
- Disable the hardware encoding and enforced AVC:444 mode on the RDP server side: Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > Prioritize H.264/AVC 444 Graphics mode for Remote Desktop Connection = Disabled;
- Try to adjust the RDP security level to RDP mode. Enable the policy ‘Require use of specific security layer for remote connections’ under the GPO section Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security and set the Security level to RDP [according to the article]. Restart the remote host to apply this setting.
After changing the local Group Policy settings on a remote server, you need to apply them on the client and server using the gpupdate command.
If you are using NIC Teaming on your Windows Server host, make sure that the receive side scaling is disabled.
- Open the Device Manager console [devmgmt.msc];
- Expand the Network adapters and open the properties of the Microsoft Network Adapter Multiplexor Driver;
- Go to the Advanced tab and set Receive Side Scaling to Disabled.
When you use a smart card certificate to authenticate on the Remote Desktop server, you may encounter the following events in the RemoteDesktopServices-RdpCoreT log on the Windows Server 2019/2016 RDS host:
Warning Event 226, RemoteDesktopServices-RdpCoreTS
General: RDP_TCP: An error was encountered when transitioning from StateUnknown in response to Event_Disconnect [error code 0x80070040]
Warning Event 142, RemoteDesktopServices-RdpCoreT
General: TCP socket READ operation failed, error 64
Make sure your certificate has not been revoked.
Now check that your RDP client connects to the remote host without errors.
Cyril Kardashevsky
I enjoy technology and developing websites. Since 2012 I'm running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.
Next PowerShell: Move Computer to OU »
Previous « How to Check Airpods Battery on Windows 10?
Share
Published by
Cyril Kardashevsky
Tags: RDPRemote Desktop
RDP Error: Remote Desktop Can’t Find the Computer
In this article, we will take a look at the basic techniques for diagnosing a…
Related Post
Recent Posts
- PowerShell
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:
| SOURCE PC: | |
| Security | 4648 |
| TerminalServices-RDPClient/Operational | 1024, 1102 |
| DESTINATION PC: | |
| LOG ON: | |
| Security | 4624, 4625 |
| TerminalServices-RemoteConnectionManager/Operational | 1149 |
| RemoteDesktopServices-RDPCoreTS /Operational | 98, 131 |
| TerminalServices-LocalSessionManager/Operational | 21, 22, 25 |
| LOG OFF: | |
| Security | 4634, 4647 |
| TerminalServices-LocalSessionManager/Operational | 23, 40 |
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.
Event 4648
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.
Event 1149
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.
Other Events
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.
Event 21
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.
Event 22
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.
Event 25
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.
Event 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.
Event 23
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.