Musings and confusings. All things DFIR.

Windows RDP-Related Event Logs: Identification, Tracking, and Investigation

Early in my DFIR career, I struggled with understanding how exactly to identify and understand all the RDP-related Windows Event Logs. I would read a few things here and there, think I understood it, then move on to the next case – repeating the same loop over and over again and never really acquiring full comprehension. That is until one day I finally got tired of repeating the same questions/research and just made a cheat sheet laying out the most common RDP-related Event ID’s that I’d encountered along with their relevance and descriptions. From that point on, as I sporadically encountered related questions/confusion from others in the community, I would simply refer to my cheat sheet to provide an immediate response or clarification – saving them from the hours of repeated questioning and research I had already done.

However, it seems the community continues to encounter the same struggle in identifying and understanding RDP-related Windows Event Log ID’s, where each is located, and even what some of them mean (no thanks to some of Microsoft’s very confusing documentation and descriptions). As such, I recently set out to try and find an easy route to the solution for this problem (i.e. hopefully find a single website to point to with all this information). Though I’ve found parts of the answer in posts here and there, each of them were missing parts of the puzzle (either missing ID’s, descriptions, explanations, and/or overall how they fit together in a chronological fashion). I will say JPCERTCC did an awesome job capturing a ton of information here, I just can’t quite decipher or discern the clear order of events and some appear out of order (at least how I have encountered them, but maybe I’m reading it wrong…). At any rate, as they say, necessity is the mother of invention.

So, I decided to create a blog post that I hope can serve as a succinct one-stop shop for understanding and identifying the most commonly encountered and empirically useful* RDP-related Windows Event Log ID’s/entries for tracking and investigating RDP usage on a Windows Vista+ endpoint. The Windows Event ID’s in the XP days were different than those in Vista+ Operating Systems. So, I decided to leave those out for now, but perhaps I will add them in the future.

*Yes, there are Event ID’s like 1146, 1147, and 1148 which look great in Microsoft’s documentation as a very useful source of information. However, I’ve yet to see (m)any of these commonly occurring in the wild.

I debated back and forth on the best way to sort/group these. Ultimately, in truly pragmatic fashion, I figured it would likely be most useful to sort them in the (chronological) order in which you might expect to find them. Ergo, the flow/section breakup is the following:

Network Connection
->-> Authentication
->-> Logon
->-> Session Disconnect/Reconnect
->-> Logoff

Network Connection

This section covers the first indications of an RDP logon – the initial network connection to a machine.

Log: Microsoft-Windows-Terminal-Services-RemoteConnectionManager/Operational

Log Location: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx

Event ID: 1149
Provider Name: Microsoft-Windows-Terminal-Services-RemoteConnectionManager
Description: “User authentication succeeded”
Notes: Despite this seemingly clear-cut description, this event actually DOES NOT indicate a successful user authentication in the sense that many might expect (e.g., successful input and acceptance of a username and password). Instead, “authentication” in this sense is referring to successful network authentication, as in someone successfully executed an RDP network connection to the target machine and it successfully responded and displayed a login window for the next step of entering credentials. For example, if I launched the RDP Desktop Connection program on my computer, input a target IP, and hit enter, it would simply display the target system’s screen and produce an 1149 Event ID indicating I had successfully connected to the target, WELL BEFORE I even entered any credentials. So, repeat after me, “An Event ID 1149 DOES NOT indicate successful authentication to a target, simply a successful RDP network connection”.
TL;DR: NOT AN AUTHENTICATION. Someone launched an RDP client, specified the target machine (possibly with a username and domain), and hit enter to make a successful network connection to the target. Nothing more, nothing less.


This section covers the authentication portion of the RDP connection – whether or not the logon is allowed based on success/failure of username/password combo.

Log: Security

Log Location: %SystemRoot%\System32\Winevt\Logs\Security.evtx

Event ID: 4624
Provider Name: Microsoft-Windows-Security-Auditing
LogonType: Type 3 (Network) when NLA is Enabled (and at times even when it’s not) followed by Type 10 (RemoteInteractive / a.k.a. Terminal Services / a.k.a. Remote Desktop) OR Type 7 from a Remote IP (if it’s a reconnection from a previous/existing RDP session)
Description: “An account was successfully logged on”
Notes: I thought this one was pretty straight forward – just look for Type 10 logons for RDP. However, in a bit more research, I discovered that often a Type 3 logon (for NLA) will occur prior to the Type 10 logon. In addition, I also discovered that RDP’ing to a system of which you’d previously RDP’ed and not formally logged off/out would instead yield a Logon Type 7 logon versus the Logon Type 10 we’d expect. This makes sense in a way in that a Logon Type 7 (“This workstation was unlocked”) is essentially what is happening. However, to delineate this from non-RDP Type 7 logons in which a person was sitting at the machine and just unlocked the machine, we can look for remote non-local IP’s in the IpAddress field.
TL;DR: User successfully logged on to this system with the specified TargetUserName and TargetDomainName from the specified IpAddress.

Event ID: 4625
Provider Name: Microsoft-Windows-Security-Auditing
LogonType: Type 3 (Network) when NLA is Enabled (and at times even when it’s not) and/or Type 10 (RemoteInteractive / a.k.a. Terminal Services / a.k.a. Remote Desktop)
Description: “An account failed to log on”
Notes: Why do we care about failures? Well, this is helpful in identifying (brute force) failure attempts and seeing when/where an attacker may be attempting stolen/compromised credentials. The Status/Sub Status Code will also be helpful in delineating legitimate failures (e.g. “expired password”) as well as possibly providing insight into attacker activity (e.g. repetitive “user name does not exist” codes could indicate brute force guessing by a tool and/or a more targeted lack of username knowledge/awareness in the environment by the attacker).
TL;DR: User failed to log on to this system with the specified TargetUserName and TargetDomainName from the specified IpAddress.


1) When NLA is enabled, a failed RDP logon (due to wrong username, password, etc.) will result in a 4625 Type 3 failure. When NLA is not enabled, you *should* see a 4625 Type 10 failure.

2) Both of these entries also contain a “SubjectLogonID” or a “TargetLogonID” field. This ID is unique for each logon session and is also present in various other Event Log entries, making it theoretically useful for tracking/delineating a specific user’s activities, particularly on systems allowing multiple logged on users. However, do take note that a unique *LogonID is assigned for each session, meaning if a user connects, then disconnects (without logging out, thus simply ending the current session), then reconnects (i.e. starting a new session), they will be assigned a different unique *LogonID. All to say that a single user(name) may have multiple unique *LogonID’s to track depending how many sessions they’ve instantiated, not to mention Windows makes it very confusing sometimes with multiple 4624’s with different *LogonID’s for the same session. So, YMMV.

Additional References:

David Cowen’s Forensic Lunch Test Kitchen – RDP Testing (1 , 2 , 3)
Microsoft Forum Answer Re: RDP 4624 Type 3 Logons (link)


This section covers the ensuing (post-authentication) events that occur upon successful authentication and logon to the system.

Log: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Log Location: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

Event ID: 21
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Session logon succeeded:”
Notes: This typically immediately precedes an Event ID 22 when the “Source Network Address” contains a remote IP address. Note that a “Source Network Address” of “LOCAL” simply indicates a local logon and does NOT indicate a remote RDP logon. this event with a “Source Network Address” of “LOCAL” will also be generated upon system (re)boot/initialization (shortly before the proceeding associated Event ID 22) . For remote RDP logons, take note of the SessionID as a means of tracking/associating additional Event Log activity with this user’s RDP session.
TL;DR: Indicates successful RDP logon and session instantiation, so long as the “Source Network Address” is NOT “LOCAL”.

Event ID: 22
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Shell start notification received:”
Notes: This typically immediately proceeds an Event ID 21. Note that a “Source Network Address” of “LOCAL” simply indicates a local logon and does NOT indicate a remote RDP logon. This event with a “Source Network Address” of “LOCAL” will also be generated upon system (re)boot/initialization (shortly after the preceding associated Event ID 21).
TL;DR: Indicates successful RDP logon and shell (i.e. Windows GUI Desktop) start, so long as the “Source Network Address” is NOT “LOCAL”.

Session Disconnect/Reconnect

This section covers the various session disconnect/reconnect events that might occur due to either system (idle), network (network disconnect), or purposeful user (X out of the RDP window, Start -> Disconnect, Kicked off by another user, etc.) action.

Log: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Log Location: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

Event ID: 24
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Session has been disconnected:”
Notes: The user has disconnected from an RDP session, when the “Source Network Address” contains a remote IP address. A “Source Network Address” of “LOCAL” simply indicates a local session disconnection and does NOT indicate a remote RDP disconnection. Note the “Source Network Address” for the source of the RDP connection. This is typically paired with an Event ID 40. Also take note of the SessionID as a means of tracking/associating additional Event Log activity with this user’s RDP session.
TL;DR: The user has disconnected from an RDP session, so long as the “Source Network Address” is NOT “LOCAL”.

Event ID: 25
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Session reconnection succeeded:”
Notes: The user has reconnected to an RDP session, when the “Source Network Address” contains a remote IP address. A “Source Network Address” of “LOCAL” simply indicates a local session reconnection and does NOT indicate a remote RDP session reconnection. Note the “Source Network Address” for the source of the RDP connection. This is typically paired with an Event ID 40. Take note of the SessionID as a means of tracking/associating additional Event Log activity with this user’s RDP session.
TL;DR: The user has reconnected to an existing RDP session, so long as the “Source Network Address” is NOT “LOCAL”.

Event ID: 39
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Session <X> has been disconnected by session <Y>”
Notes: This indicates that a user has formally disconnected from an RDP session via purposeful Disconnect (e.g., via the Windows Start Menu Disconnect option) versus simply X’ing out of the RDP window. Cases where the Session ID of <X> differs from <Y> may indicate a separate RDP session has disconnected (i.e. kicked off) the given user.
TL;DR: The user formally disconnected from the RDP session.

Event ID: 40
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Session <X> has been disconnected, reason code <Z>”
Notes: In true Microsoft fashion, although the description is always “Session has been disconnected”, these events also indicate/correlate to reconnections, not just disconnections. The most helpful information here is the Reason Code (a function of the IMsRdpClient::ExtendedDisconnectReason property), the list of which can be seen here (and this pairs it with the codes to make it easier to read). Below are some examples of codes I encountered during my research.
0 – “No additional information is available.” (Occurs when a user informally X’es out of a session, typically paired with Event ID 24)
5 – “The client’s connection was replaced by another connection.” (Occurs when a user reconnects to an RDP session, typically paired with an Event ID 25)
11 – “User activity has initiated the disconnect.” (Occurs when a user formally initiates an RDP disconnect, for example via the Windows Start Menu Disconnect option.)
TL;DR: The user disconnected from or reconnected to an RDP session.

Log: Security

Log Location: %SystemRoot%\System32\Winevt\Logs\Security.evtx

Event ID: 4778
Provider Name: Microsoft-Windows-Security-Auditing
Description: “A session was reconnected to a Window Station.”
Notes: Occurs when a user reconnects to an existing RDP session. Typically paired with Event ID 25. The SessionName, ClientAddress, and LogonID can all be useful for identifying the source and associated activity.
TL;DR: The user reconnected to an existing RDP session.

Event ID: 4779
Provider Name: Microsoft-Windows-Security-Auditing
Description: “A session was disconnected from a Window Station.”
Notes: Occurs when a user disconnects from an RDP session. Typically paired with Event ID 24 and likely Event ID’s 39 and 40. The SessionName, ClientAddress, and LogonID can all be useful for identifying the source and associated activity.
TL;DR: The user disconnected from from an RDP session.


This section covers the events that occur after a purposeful (Start -> Disconnect, Start -> Logoff) logoff.

Log: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational

Log Location: %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx

Event ID: 23
Provider Name: Microsoft-Windows-TerminalServices-LocalSessionManager
Description: “Remote Desktop Services: Session logoff succeeded:”
Notes: The user has initiated a logoff. This is typically paired with an Event ID 4634 (logoff). Take note of the SessionID as a means of tracking/associating additional Event Log activity with this user’s RDP session. This event with a will also be generated upon a system shutdown/reboot.
TL;DR: The user initiated a formal system logoff (versus a simple session disconnect).

Log: Security

Log Location: %SystemRoot%\System32\Winevt\Logs\Security.evtx

Event ID: 4634
Provider Name: Microsoft-Windows-Security-Auditing
LogonType: 10 (RemoteInteractive / a.k.a. Terminal Services / a.k.a. Remote Desktop) OR Type 7 from a Remote IP (if it’s a reconnection from a previous/existing RDP session)
Description: “An account was logged off.”
Notes: These occur whenever a user simply disconnects from an RDP session or formally logs off (via Windows Start Menu Logoff). This is typically paired with an Event ID 21 (RDP Session Logoff). I’ve also discovered these will also be paired (i.e. occur at the same time) with successful authentications (Event ID 4624). Why, I have no idea.
TL;DR: A user disconnected from, or logged off, an RDP session.

Event ID: 4647
Provider Name: Microsoft-Windows-Security-Auditing
Description: “User initiated logoff:”
Notes: Occurs when a user initiates a formal system logoff and is not necessarily RDP specific. You will need to use some reasoning and temporal analysis to understand if/when it is related to a system logoff via an RDP session or is from a local interactive session as there is no LogonType associated specify which it is.
TL;DR: The user initiated a formal logoff (NOT a simple disconnect).

Log: System

Log Location: %SystemRoot%\System32\Winevt\Logs\System.evtx

Event ID: 9009
Provider Name: Desktop Window Manager
Description: “The Desktop Window Manager has exited with code (<X>).”
Notes: Occurs when a user formally closes an RDP connection and indicates the RDP desktop GUI has been shut down as a result. This is useful to identify a closed/finalized RDP connection. Though, this event is not always produced for reasons I do not know.
TL;DR: A user has closed out an RDP connection.


Hopefully that provides a little better insight into some of the most common and (IME) most empirically useful RDP-related Event logs, when/where you might encounter them, what they mean, what they look like, and (most importantly) how they all fit together.

As a result of this post, Richard Davis (@richarddavisg, @13CubedDFIR) of 13Cubed on YouTube has also put together an RDP flow chart that is very helpful in visualizing the expected (though, not guaranteed) flow of these logs. Feel free to check out his short video walkthrough as well.


Generating File System Listings from the Command Line (with Full MACB Timestamps and Hashes)


  1. RDP

    Thank you for putting the effort into this and sharing with the community. Only one ask. When doing an RDP from the source as windows to the destination, please also add, to the above, where will the documented log be found, on the source or on the destination.

    • Thanks for the feedback. That’s a great question. All of the Event ID’s referenced in this post will be found within the logs on the target system (the endpoint that is receiving the remote RDP connection).

      Historically, the main artifact on a source system (the system connecting to another system via RDP) was a prefetch entry for mstsc.exe (the RDP client executable) – namely However, I’ve recently discovered another source of Event ID’s that provide indication and information on RDP connections to other systems. These events lie within the Microsoft-Windows-TerminalServices-RDPClient/Operational log (location on disk is %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-RDPClient%4Operational.evtx). When a source machine attempts to connect to a target, various Event ID’s are logged here indicating the name/IP of the target as well as various related connection and disconnection messages which can also be helpful when investigating a system that is the source of RDP connections to other machines.

      Perhaps I will do another short write-up on that at some point in the future, or will send it out to the community and see if someone else has time to do so.

  2. Thanks for expanding on this. I always jump to event id 4625 as a matter of routine, you’ll see multiple failed attempts on this ID if the bad guys are trying to brute force a password on your server. Changing your RDP listening port significantly cuts out the ‘noise’ from the internet. 🙂

  3. Loumos

    Nice job ! Very usefull ! Maybe you should talk about NLA authentication which change RDP logon tracking.
    I also try to clarify simple login for SIEM investigation : when à user authenticate to an AD. I could help you for this part let me know ! 🙂

    • Thanks! This post focuses on RDP using NLA Authentication. It doesn’t cover what would be logged at the AD for Kerberos or other authentication types as that’s out of scope for the focus here (identifying/parsing event logs on the endpoints/workstations). Do feel free to do a writeup on the AD aspect, though, as that could also be helpful.

  4. Joe

    Great write up Jonathon!
    Is there a free tool that aggregates all the windows event logs to display the chain of events?

    • Thanks! There are a few different tools you can use, each with varying levels of effort/involvement. The most popular and straight forward (once installed) tool is probably Plaso’s Log2timeline ( as it has binaries available for Windows, Linux, and Mac. You can simply extract all Windows event logs into a single folder and point log2timeline at the folder with the appropriate parser (winevt or winevtx) and let it rip. In the end (after running psort to output into a CSV or whatever file output type you like) you’ll have all* the processed Windows event logs in human readable form.

      *Plaso/Log2timeline has been known to have sporadic issues parsing things, so… caveat emptor.

      If you’re less comfortable in Linux or with the command line, Microsoft also has some great tools for parsing event logs called Log Parser (, along with a “Studio” version ( with some additional GUI bells and whistles. There is also another tool called Log Parser Lizard ( which is another free GUI tool for Windows to parse event logs.

      At any rate, I could probably write an entire blog post itself on various ways to parse those logs, but hope the above helps!

  5. Jason


    This blog is awesome!

    I trying to replicate 1149 (connection without authentication) however I can only get this log when RDP is successfully authenticated. I have also tried using a different RDP client. Both machines are Windows 10. Seems to be only logging an event with ID 261

    Can you confirm your setup?

    • Thanks for the feedback, Jason. Glad it has been helpful to you!

      That is interesting… I’ve tested/verified this by a) Using a Win7 system to RDP to both Win7 and Win10 systems, and b) investigating Win7 and Win10 systems for RDP behavior. Though, Windows is ever-changing, so I wonder if something may be different in a Win10 -> Win10 setup or if something else is going on here. I can’t personally test at the moment, but obviously can’t argue your experience here. Though it doesn’t change the “1149 does not itself indicate a successful authentication”, it does change the perspective that these entries may not even be present on some Win10 onward systems (as would otherwise be useful to denote even unsuccessful attempts) unless a successful authentication has occurred (assuming something else isn’t going awry here).

      I will reach out to Twitter #DFIR to see if anyone else can test/confirm/corroborate for the time being…

  6. Cody

    For what it’s worth, and just an interesting note. You have Event ID 21 with an IP address of “LOCAL”. Based on testing this is merely a logon and not an RDP session. It appears that a logon will add an Event 21/22 with address of “LOCAL” to the \System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx.

    In my testing I found that Event 21/22 with an actual IP address listed is a clear sign of RDP session, but don’t state that simply an event id 21/22 with IP of “LOCAL” indicated an RDP session.

    Not sure if you came to the same conclusion, but do some testing and let me know what you think.

    • Hi Cody,

      Thanks for the comment. That is a great point. You’re totally correct in that anything with a SourceNetworkAddress of “LOCAL” would indicate a local logon and not one from a remote machine (hence, the “LOCAL”). This actually applies not just to EID 21, but also 22, 24, and 25.

      Great catch on my mistake in my event log capture for that example. I obviously captured the wrong one(s) and will update the screenshots here shortly to provide the proper example(s).

      This is also a good time to remind everyone that this series is intended to denote a combination of logs that, when culled together and analyzed as a whole, can help indicate and track RDP logon history for a target. It was purposefully put together this way as Windows can be extremely ambiguous, unreliable, and downright initially confusing in what it logs (or does not).

      This is actually a great example of where simply looking at an individual log can be very deceiving and confusing if you aren’t looking at everything that also occurred (or did not) before and after, or simply are not yet well versed in RDP event log investigations. If we found an Event 21 in the logs without other surrounding supporting logs, we would want to take a step back and ask why they weren’t found. In this case, there would be no surrounding supporting RDP events because a 21 with a “LOCAL” source is not in fact an RDP logon as you’ve very aptly pointed out.

      Thanks for reading the blog/post and thanks again for your feedback. This was a great two-for (an opportunity to fix an error I’ve made as well as provide some additional context/tips for encountering EID’s with a “LOCAL” source). I’ve edited all the sections where this is applicable (namely for EID’s 21, 22, 24, and 25).

      Please let me know if you find any other additions or mistakes. Windows seems to be updating some of its core functionality and logging more and more frequently. So it is inevitable this will need to be updated many more times to come.


  7. Ray

    Thanks for your great post! Can You tell me where i can learn about the session ID’s? What does a session like 2 tell me?

  8. Sean

    Hi Jonathon,
    Great blog!! Very informative.
    I’m trying to understand why a LOCAL logon (within Event ID 21) would be recorded within the Remote Desktop Services logs?
    Does this indicate logging onto the physical machine or logging on remotely via a device on the same network?

    • Hi Sean,

      Thanks for the compliment! And, thanks for the question.

      As I note in my post, an EID 21 with “LOCAL” as the “Source Network Address” indicates a local logon (person locally sitting at keyboard logging on) and NOT an RDP logon. A true RDP logon will have an EID 21 with a remote machine’s IP in the “Source Network Address” field and will be proceeded by an EID 22 with the same remote IP. It’s a bit confusing, I know.

      I wish I could tell you why, for whatever reason(s), Microsoft logs a LOCAL logon within the RDP LocalSessionManager log but I have no idea. This is just another one of those things where (at least for the meantime) you just make a note that it occurs so you don’t get hung up on it for future investigations. Perhaps someday someone can find out why through some more targeted testing and perhaps direct interrogation with MS, but for now it’s just one of those things (at least for me).

      Hopefully that clears it up a bit. If not, try re-reading the paragraphs a few more times until it hopefully sinks in. I had to do that many times myself until I was finally able to grok it all.

      Thanks again for reading and for the question!


      • John Hanson

        Hi Jonathan! This blog is of great value to the community!

        I have a question that isn’t exactly related to the previous entry: what is event ID 59? I have a log that contains several lines where there is an event 23 indicating a logoff, then followed by an event 24 indicating a disconnect, followed by event 39, and also a 59.

        Unless I misunderstand events 23 and 24, this looks like something unusual occurred. Most of the time, I don’t see 24 occurring with an associated 23, and wondered what this means.



        • Hi John,

          Thanks for the kind words, as well as the questions here.

          With regard to seeing Event ID 23, 24, and 39 together/in sequence, you are experiencing very normal activity. To understand when/how/why these might occur together (and in certain orders) you need to understand that events are often very atomic – one specific thing occurred and I am reporting on it (without respect or context to other things). The logging system doesn’t care what happened before or after a given event, just that a specific event occurred that it needs to log and it does so.

          So, when you think about things in a very silo’ed and atomic approach like this, you can start understanding that a formal logoff from an endpoint might very well include several sequential atomic operations of EID 23 (user initiates formal logoff), followed by EID 24 (the formal logoff initiates an RDP disconnection), followed by EID 39 (the RDP session has been disconnected/killed). In this vein, a disconnect would also include a EID 24 followed by a EID 39 and/or an EID 40 (but no EID 23 as there wasn’t a formal logoff, just a disconnect via “X”ing our or similar).

          It is up to us as the humans to (attempt to) build the context and piece together the puzzle by putting all of these disparate atomic entries into a cohesive story of what (might have) happened. As you can see, the pairings and sequences depend on the action performed. So, both the presence and lack of presence of certain EID’s can help us determine the action(s).

          Though, the major caveat in all of this is that while we know what often “should” occur, sometimes Windows just flubs it up and does/doesn’t produce something we expect. So, at times it takes a bit of educated guessing (sorry, it just is) if we have overwhelming reason to believe something did/didn’t happen but we are missing one or two pieces of information that don’t fit into the puzzle. Sometimes there are valid explanations that we don’t yet realize, and sometimes unfortunately there just isn’t an explanation and we’ve got to do our best to properly document the surrounding context that underpins our assessment.

          This often nebulous and confusing situation of trying to put together a story from a wide array of EID’s was the genesis of me putting together this walkthrough to help people better piece these things together for RDP connections.

          To also assist, Richard Davis ( put together a rather useful flowchart for RDP that helps provide a nice visual for the (expected) flow of RDP event logs based on certain actions:

          All that said, I’m not too familiar with Event ID 59’s. I’ve looked them up and see there is a subsection of the message called “ProcessingErrorData” with an associated “ErrorCode”, as well as ProcessID and ThreadID entries leading me to believe this may be more of a process error than anything directly relevant to tracking RDP connections. However, this is just my (marginally) educated guess as I’ve not had much direct experience with these.

          At any rate, hopefully that provides a better understanding of why you’re seeing what you’re seeing. If not, please let me know and I’ll do my best to address in a different approach.

          Thanks again for the feedback and questions.


  9. Javier Bruno

    Hello! thanks for this post. Was very useful but I couldnt finish what I came here to do. I wanted to log logon failures on RDP. so If I have like 3, block a connection (thru a tool called Eventsentry based on eventlog) BUT, as you marked here, even log for that should be 4625, on logon type 10. But in my windows (2012, 2016, part of an AD and stand alone, both) just logs the logon failure as type 3. which is the same type of any other logon failure. Your screenshot and text export shows the same (no type 10 logon). Do you thing a way how I can specifically track logon failures for RDP? THANKS

    • Hi Javier,

      Thanks for reading my post and the great question. I love when questions/challenges help me update my post (and this is another great example).

      You are correct – with the advent of NLA (Network Level Authentication) you will actually see Type 3 Logons for both 4624 and 4625 events (versus the Type 10 you might expect). I believe this started in Windows 10 (someone correct me if I’m wrong), and the reason for this is that Windows will first attempt to use NLA for authentication (even if you don’t have it configured) thus resulting in a Type 3 Logon for either a 4624 or 4625.

      In the case of a failed logon, you will likely only see a 4625 Type 3 failure and not a Type 10 (but do not quote me on this, as we know things can be somewhat random with Event log stuff in Windows).

      In the case of a successful logon, you will likely see a 4624 Type 3 followed by a 4624 Type 10. Again, I say “likely” see that as it has been sporadic in my testing (and others’ testing as well).

      I have updated my post and attached screenshots to correct and (as best as possible) reflect this. I have also added NLA references, a reference to the Microsoft Forum answer to this, as well as references to David Cowen’s Forensic Lunch Test Kitchen 3-part series where he walks through real-time testing and realization of how wonky Windows event logging (especially with regard to RDP) is.

      At any rate, thanks again for the question. Everyone can now benefit from better clarity surrounding 4624/4625 events because of it.

      – JP

      • Javier Bruno

        Wow, thanks for the quick reply. I was doing a lot of testing to find this and somehow somewhere I edited group policy of the computer (Im guessing) and in one of the SO testing I got an event ID 140 in /app serv logs/Microsoft/windows/RemoteDesktopServices-RdpCoreTS/Operational, where it says the bad login and ip address too! but at this point I do not know for sure that I changed, since I test the same on fresh SO and that ID error wont be logged. I will keep trying 🙂 thanks for your reply again

        • Hi Javier,

          Yes, you’ve hit on another area that I’ve had earmarked in my notes to update as well.

          The Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational.evtx log provides some additional logs (namely 102, 103, 131, and 140) that help identify RDP connections (at times with source information lacking in other logs), and especially help when attempting to determine whether a 4624/4625 Type 3 was in fact an RDP (attempted) logon or simply a network logon.

          Stay tuned for updates at some point in the hopefully not too distant future.

          Thanks again for the question, insight, and responses.


  10. X

    Had to thank you for this write-up. After finding out about CVE-2019-0708, I wanted to make sure I was the only one accessing my desktop! Now I can sleep at night. Shared your post.

  11. Neil Torpey

    Very helpful resource, thanks for putting this together!

  12. Hello,

    I just wanted to put out there that I identified something that i’ve only found one other person in my google search to actually bring up. My Event Log Reads like this:


    WHat is RDSAppXPlugin? I’m guessing Some security type app for Law enforcement purposes? Thought I’d see how common this is.


    • Hi Joseph,

      That is an interesting Event ID I do not recall noticing and had not researched. And, you’re right, there’s very little out there documenting its significance (if any).

      So, I did a little bit of testing on my end. Turns out, this appears to simply be related to the RDP startup process(es) that occurs upon system start/reboot. You will see it intermingled with many of the startup events that occur on a system. As such, from my research/testing, it does not indicate anything more than that.

      Given it’s only related to RDP initialization, I’m not sure it’s worth documenting as related to RDP logon/logoff investigations.


      In my testing, I did observe that Microsoft-Windows-TerminalServices-LocalSessionManager/Operational Event ID 23 will occur upon a system shutdown, and Event ID’s 21 and 22 will occur upon system boot/initialization with “Source Network Address: LOCAL” (even before any user-initiated login), which I think is worth nothing in the article in terms of notes/caveats for each. So, I will update this shortly with those additional data points.

      Thanks for the question, and I hope this helped to answer it!


  13. Roman

    First at all great article, it helped me already with some analysis.

    But i would have a short question about an reason code i receive in the TerminalServices-LocalSessionManager Log, maybe you can help me with it:

    “Session 90 has been disconnected, reason code 3489660929”

    What is the reason code: 3489660929?

    Currently my users are experiencing random disconnects on my RDS 2019 Farm where always this reason code pops up.

  14. o2

    Thanks for your post.
    What if I see a 4779 event ID with client address:::1, how do we get the IP address?
    We only have the client name but no IP address. What do you advice?

    • Thanks for the thanks!

      If you see a 4779 with a local address, it may just be part of a local logoff. As I explain in parts of my post, there are RDP-related events even for local logons/logoffs, which you will need to discern by source address being local type and/or surrounding context from other event ID’s.

      Hard to say without surrounding Event ID’s for context, but that is what I would use to deduce what is occurring.

      Hope that helps!


  15. I hope someone else has experienced what I am with several Windows 2012R2 RDS Hosts and the LocalSessionManager / Operational log: No matter how the log properties are changed via GPO (registry edits as there are no templates for these logs) or in the GUI the log will not grow over 1MB. This is a major PITA as we are using this as part of our COVID-19 response plan read and processed by a powershell application I wrote. I am at the point of pulling off the logs daily to keep a record but with 10 hosts serving RDS it would be preferable to read the logs when necessary without the upfront processing efforts for logs that may never be used.

    Does anyone know why this is and how to work around it?

    Thank you in advance.

    • Hi Sean,

      I can’t directly speak to the maximum log file size configuration not sticking/working. Hopefully others can.

      However, I did want to suggest considering implementing Windows Event Forwarding (WEF) from your RDS (and any other important) servers to a centralize log repository/SIEM. It’s actually a good idea (i.e. best practice) to ship logs off the endpoints to a centralized and secured repository to avoid data loss issues (due to both explicit attacker deletion or configuration issues like this) as well as provide more effective environment-wide data searching during investigations.

      HereHere is a great Microsoft resource for understanding and implementing WEF. However, there are tons of resources available with walkthroughs, like herehere and herehere.

      Anyway, hope that helps!


  16. Sema

    Thank you for your great information in this post. I have a question and I hope you can reply it. I am working on RDP events, in addition to these events mentioned here there are a wide range of events occurring during testing this software by various predetermined scenarios such as event IDs 142,143,226 and so on. How can I get a complete document about event IDs have been occurring?

    • Hi Sema,

      Thanks for reading my blog, the kind words, and the follow-up question.

      As you can see, there isn’t a single source to go to (that I’m aware of) that comprehensively covers all applicable RDP-related events and ID’s, particularly for both the target and host.

      In this blog post, I attempted to cover most of the target system event ID’s of importance as those are most often what are being analyzed for possible compromise. That said, I’ve collected additional events and ID’s since initial authoring of this post that should also be included – some of which you’ve noted in your comment and I’ve also noted in my response to a similar comment/question here.

      The plan is to update this post in the future, as well as author another separate post that will cover a lot of the client side events and ID’s as well.

      As you can see, there is just so much to cover and so little time 🙂

      At any rate, I hope what I have at least helped more than having to spend a ton of time doing Google searches and attempting to piece a bunch of disparate things together.


  17. akira yan

    Thanks for the detailed description of these event IDs.
    I found one is missed.
    If the account does not have permission to logon via RDP, i.e. not in the group “Remote Desktop Users” or not in the Administrators group, the remote server will deny the connection, and in the security.evtx of source host, there is an eventID=4825 (RDP denied).

    • Hi Akira,

      Thanks for the kind words and feedback.

      Correct, logon failures (including RDP incorrect password and explicitly denied users) are capture in Security Event ID 4825 on the target (even when the username doesn’t exist. However, I’m not aware if that error is also logged on the source host as well. Have you tested and verified this? If so, that would be good to note for future “client side” series on RDP.


Leave a Reply

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

No Bots. No Spam. *

Powered by WordPress & Theme by Anders Norén