ponderthebits.com Open in urlscan Pro
2607:f1c0:100f:f000::220 Public Scan

Back to summary

URL:
https://ponderthebits.com/2018/02/windows-rdp-related-event-logs-identification-tracking-and-investigation/
Submission: On July 16 via api (July 16th 2024, 1:45:18 pm UTC) from US — Scanned from DE

Form analysis
3 forms found in the DOM

GET https://ponderthebits.com/

<form method="get" class="search-form" id="search-form-66967967bf249" action="https://ponderthebits.com/">
  <input type="search" class="search-field" placeholder="Search form" name="s" id="s-66967967bf24a">
  <button type="submit" class="search-button">
    <div class="genericon genericon-search"></div><span class="screen-reader-text">Search</span>
  </button>
</form>

POST https://ponderthebits.com/wp-comments-post.php

<form action="https://ponderthebits.com/wp-comments-post.php" method="post" id="commentform" class="comment-form">
  <p class="comment-notes"><span id="email-notes">Your email address will not be published.</span> <span class="required-field-message">Required fields are marked <span class="required">*</span></span></p>
  <p class="comment-form-comment"><label for="comment">Comment <span class="required">*</span></label> <textarea id="comment" name="comment" cols="45" rows="8" maxlength="65525" required="required"></textarea></p>
  <p class="comment-form-author"><label for="author">Name <span class="required">*</span></label> <input id="author" name="author" type="text" value="" size="30" maxlength="245" autocomplete="name" required="required"></p>
  <p class="comment-form-email"><label for="email">Email <span class="required">*</span></label> <input id="email" name="email" type="text" value="" size="30" maxlength="100" aria-describedby="email-notes" autocomplete="email" required="required">
  </p>
  <p class="comment-form-url"><label for="url">Website</label> <input id="url" name="url" type="text" value="" size="30" maxlength="200" autocomplete="url"></p>
  <p class="cptch_block"><span class="cptch_title">No Bots. No Spam.<span class="required"> *</span></span>
    <script class="cptch_to_remove" type="text/javascript">
      (function(d, tag, id) {
        var script = d.getElementById(id);
        if (script) return;
        add_script("", "", id);
        if (typeof(cptch_vars) == "undefined") {
          var local = {
            nonce: "8430f4a273",
            ajaxurl: "https://ponderthebits.com/wp-admin/admin-ajax.php",
            enlarge: ""
          };
          add_script("", "/* <![CDATA[ */var cptch_vars=" + JSON.stringify(local) + "/* ]]> */");
        }
        d.addEventListener("DOMContentLoaded", function() {
          var scripts = d.getElementsByTagName(tag),
            captcha_script = /https:\/\/ponderthebits.com\/wp-content\/plugins\/captcha\/js\/front_end_script.js/,
            include_captcha = true;
          if (scripts) {
            for (var i = 0; i < scripts.length; i++) {
              if (scripts[i].src.match(captcha_script)) {
                include_captcha = false;
                break;
              }
            }
          }
          if (typeof jQuery == "undefined") {
            var siteurl = "https://ponderthebits.com";
            add_script(siteurl + "/wp-includes/js/jquery/jquery.js");
            add_script(siteurl + "/wp-includes/js/jquery/jquery-migrate.min.js");
          }
          if (include_captcha) add_script("https://ponderthebits.com/wp-content/plugins/captcha/js/front_end_script.js");
        });

        function add_script(url, content, js_id) {
          url = url || "";
          content = content || "";
          js_id = js_id || "";
          var script = d.createElement(tag);
          if (url) script.src = url;
          if (content) script.appendChild(d.createTextNode(content));
          if (js_id) script.id = js_id;
          script.setAttribute("type", "text/javascript");
          d.body.appendChild(script);
        }
      })(document, "script", "cptch_script_loader");
    </script><span class="cptch_wrap cptch_recognition">
      <label class="cptch_label" for="cptch_input_74"><span class="cptch_images_wrap"><span class="cptch_span">3</span><span class="cptch_span">5</span><span class="cptch_span">8</span></span>
        <input id="cptch_input_74" class="cptch_input cptch_wp_comments" type="text" autocomplete="off" name="cptch_number" value="" maxlength="3" size="3" aria-required="true" required="required"
          style="margin-bottom: 0px; font-size: 12px; max-width: 100%; width: 44px;">
        <input type="hidden" name="cptch_result" value="VQQCkQ=="><input type="hidden" name="cptch_time" value="1721137513">
        <input type="hidden" name="cptch_form" value="wp_comments">
      </label><span class="cptch_reload_button_wrap hide-if-no-js">
        <noscript>
          <style type="text/css">
            .hide-if-no-js {
              display: none !important;
            }
          </style>
        </noscript>
        <span class="cptch_reload_button dashicons dashicons-update"></span>
      </span></span>
  </p>
  <p class="form-submit"><input name="submit" type="submit" id="submit" class="submit" value="Post Comment"> <input type="hidden" name="comment_post_ID" value="275" id="comment_post_ID">
    <input type="hidden" name="comment_parent" id="comment_parent" value="0">
  </p>
</form>

GET https://ponderthebits.com/

<form method="get" class="search-form" id="search-form-66967967ca2dc" action="https://ponderthebits.com/">
  <input type="search" class="search-field" placeholder="Search form" name="s" id="s-66967967ca2dd">
  <button type="submit" class="search-button">
    <div class="genericon genericon-search"></div><span class="screen-reader-text">Search</span>
  </button>
</form>

Text Content

Skip to the content
Ponder The Bits

MUSINGS AND CONFUSINGS. ALL THINGS DFIR.

Toggle the mobile menu

Toggle the search field
* Home
* Presentations & Podcasts
* About Me
* DFIR Resources

Search
* Home
* Presentations & Podcasts
* About Me
* DFIR Resources

WINDOWS RDP-RELATED EVENT LOGS: IDENTIFICATION, TRACKING, AND INVESTIGATION

By Jonathon Poling

On February 20, 2018

In Event Logs, Forensics, Incident Response, RDP, Remote Desktop, Uncategorized,
Windows

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.

AUTHENTICATION

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.

#ProTip(s):

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)

LOGON

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.

LOGOFF

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.

WRAP-UP

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)

54 COMMENTS

Add Comment →

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.

March 3, 2018

* JONATHON POLING

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 MSTSC.EXE-462193BE.pf. 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.

March 3, 2018

2. SYMMETRIC

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.

March 7, 2018

* JONATHON POLING

Glad I could help

March 7, 2018

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 !

March 11, 2018

* JONATHON POLING

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.

March 11, 2018

4. JOE

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

March 20, 2018

* JONATHON POLING

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
(https://github.com/log2timeline/plaso) 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
(https://technet.microsoft.com/en-us/scriptcenter/dd919274.aspx), along
with a “Studio” version
(https://gallery.technet.microsoft.com/office/Log-Parser-Studio-cd458765)
with some additional GUI bells and whistles. There is also another tool
called Log Parser Lizard (https://lizard-labs.com/log_parser_lizard.aspx)
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!

March 20, 2018

5. JASON

Hi,

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?

July 16, 2018

* JONATHON POLING

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…

July 17, 2018

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.

August 19, 2018

* JONATHON POLING

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.

August 19, 2018

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?

October 17, 2018

* JONATHON POLING

Hi Ray,

I presume you are referring to and not the “Logon ID” or “Linked Logon
ID” you might encounter in various event logs.

Here is a quick rundown on RDP Sessions.

You can query the existing sessions (including RDP and local) on a
machine by using the “quser”, “query session”, and/or “qwinsta” commands
on an endpoint.

And, just for fun reading, you can see how you can shadow an RDP session
on an endpoint.

http://woshub.com/rds-shadow-how-to-connect-to-a-user-session-in-windows-server-2012-r2/

Let me know if that doesn’t answer the question.

November 18, 2018

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?

December 8, 2018

* JONATHON POLING

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!

December 10, 2018

* 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.

Thanks,

John

February 5, 2019

* JONATHON POLING

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 (https://twitter.com/davisrichardg) 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:

https://www.13cubed.com/downloads/rdp_flowchart.pdf

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.

-JP

February 6, 2019

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

June 12, 2019

* JONATHON POLING

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

June 12, 2019

* 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

June 15, 2019

* JONATHON POLING

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.

June 16, 2019

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.

June 13, 2019

* JONATHON POLING

Thanks for the kind words and feedback. Glad it could help!

– JP

June 13, 2019

11. NEIL TORPEY

Very helpful resource, thanks for putting this together!

August 16, 2019

12. JOSEPH WILLIAM REDFIELD

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:

–
RDSAppXPlugin

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

Thanks

September 30, 2019

* JONATHON POLING

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.

However…

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!

October 1, 2019

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.

November 6, 2019

* JONATHON POLING

Hi Roman,

Thanks for the feedback!

Unfortunately, disconnect codes are hard to come by. In my cursory
search, I found a post here that infers it may be related to users
getting bumped from a server. However, it’s really hard to say.

All I can offer at this point is a couple links to disconnect codes I’ve
come across and keep for my reference, though I don’t see your specific
code in the below links.

https://social.technet.microsoft.com/wiki/contents/articles/37874.rds-session-host-server-disconnect-codes.aspx
https://social.technet.microsoft.com/wiki/contents/articles/37870.remote-desktop-client-troubleshooting-disconnect-codes-and-reasons.aspx

Hope that at least helps a bit or gets you on the right path.

November 16, 2019

* MARK

Hi Roman, hopefully this reaches you. Did you find a solution to this?
Running into the same reason code, similar circumstances.

April 8, 2020

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?

November 6, 2019

* JONATHON POLING

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!

November 16, 2019

15. SEAN TRIMM

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.

May 4, 2020

* JONATHON POLING

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!

May 5, 2020

16. SEMA

HI
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?

June 24, 2020

* JONATHON POLING

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.

August 11, 2020

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).

June 27, 2020

* JONATHON POLING

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.

August 11, 2020

18. ALEX

Hello Jonathon

Pardon me if missed, but how about event ids for events initated by server
(e.g. due to group policies linked to terminating long time disconnected
sessions)?

Regards

August 24, 2020

* JONATHON POLING

Hi, Alex. Good question. See my response to a similar question from Jeff!

March 19, 2021

19. METALLINE

Great article, thanks! There is also a good article related to rdp logs
here –
https://sysadminpoint.com/2020/07/13/how_to_view_rdp_connection_logs_in_windows/

August 28, 2020

20. JULIE

Hello,
How can I determine who is killing rdp connections for other users?

September 14, 2020

* JONATHON POLING

Hi Julie,

I would suggest doing some timeline analysis of the RDP events as they
occur chronologically. I’d imagine you would be able to piece this
together by following the trail of disconnects and the subsequent
connection.

Hope that helps.

March 19, 2021

21. JEFF

Jonathan,

For a beginner this is such a great compilation of information regarding
the sequence of RDP events. Thank you so much for putting this together as
I’ve found it very educational / informative. That said I have one question
which you may be able to quickly answer. Within GPOs there are two
settings: “set time limit for disconnect session” and “set time limit for
active but idle RDP session”… which allow a forced disconnect of an idle
RDP session to the target server the GPO is applied to. In the event that
an RDP session is killed due to either of these settings, what would the
logs look like that would allow me to uniquely identify this from other
disconnects? I assume I would see event ID 24 for a disconnect, paired with
event ID 40 and a reason code of 3 (for idle time out) or 4 (for time
limit).

Thanks for your time and response,
Jeff

December 28, 2020

* JONATHON POLING

Hi, Jeff. Good question!

I’d actually have to test to see myself. Perhaps you could do the same
and report back? That would be good to know, for sure.

March 19, 2021

* SALOMON

Setting up a GPO to disconnect an idle session after 1 hour. It creates
an event under
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational Event
ID 40, Session has been disconnected, reason code 3.

January 25, 2024

22. FABIO

Perfect Information. Thank you very much for making this content available.
I am doing an analysis in my environment and I receive several connections
and disconnections with the sequences of reasons 0 and 5 in eventvwr
(Microsoft-Windows-TerminalServices-LocalSessionManager) EventID 40.

Do you have any idea why my users have multiple disconnections and
simultaneous connections?

January 4, 2021

* JONATHON POLING

Hi, Fabio. Thanks for the question.

Here is a reference to the reason codes for that event.
https://docs.microsoft.com/en-us/windows/win32/termserv/extendeddisconnectreasoncode

Those codes correlate to:

0 – No additional information is available. (not very helpful)
5 – The client’s connection was replaced by another connection.

So, it seems that you are reaching the maximum amount of simultaneous
user connections allowed at once, and thus it is replacing certain
existing connections with the new one(s).

I would look into how to adjust the number of simultaneous connections
for your endpoint as a possible solution.

Hope that helps!

March 19, 2021

23. MARTIN

Great article. Very helpful.
The information provided a very up-to-date help in the avalanche of a
ransomware extortion crime. Thank you for the valuable information.

Greetings from Germany
Martin

March 19, 2021

* JONATHON POLING

Thanks, Martin. I appreciate the feedback and glad it could help you out!

March 19, 2021

24. ANKIT

Would it be ‘normal’ to see 4624 type 3 events on a DC ? From my
understanding, those are logon events and not account logon
(authentication) events and should be logged on the actual resource /
destination host.

April 12, 2021

* JONATHON POLING

Hi Ankit,

Yes, those are normal to see on the DC when leveraging AD/Kerberos from
members logging onto the domain and their workstations.

May 9, 2021

25. AJS

THANK YOU.

August 29, 2022

26. PETER

It’s the year 2023 and we are still grateful for this amazing &
comprehensive write-up.
Thanks a lot man!

February 2, 2023

13 PINGBACKS

1. Windows RDP-Related Event Logs: Identification, Tracking, and Investigation
– Cyber Forensicator

2. Remote Desktop Connection (RDC) Failed | Linux, Windows, Heklanje, Kuhinja

3. Remote Connection Dashboards: VNC & RDP - Syspanda

4. Remote Desktop Connection (RDC) Failed, RDC WIN7 to WIN7 | Linux, Windows,
Crochet, Kitchen

5. Adventures of an RDP Honeypot – Part One: RDP Security - TrustedSec

6. Adventures of an RDP Honeypot – Part One: RDP Security - f1tym1

7. RDP Event Log DFIR – DFIR on the Mountain

8. MOV AX, BX Code depilation salon: Articles, Code samples, Processor code
documentation, Low-level programming, Working with debuggers RDP Event Log
DFIR

9. Forense em Logs de Evento RDP – TI Forense

10. How to avoid using RDP on Windows – pcsecurity-99.com

11. Elementor #2444 – TRANQUIL SECURITY

12. Track Remote Desktop Login RDP activities | Baysoft's Blog

13. Part 3: Intro to threat hunting – Hunting the imposter among us with the
Elastic stack and Sysmon | HoldMyBeer

ponderthebits.com Open in urlscan Pro 2607:f1c0:100f:f000::220 Public Scan

Form analysis 3 forms found in the DOM

GET https://ponderthebits.com/

POST https://ponderthebits.com/wp-comments-post.php

GET https://ponderthebits.com/

Text Content

ponderthebits.com Open in urlscan Pro
2607:f1c0:100f:f000::220 Public Scan

Form analysis
3 forms found in the DOM