Welcome back! As promised, this post will be focused on part of of “Lateral Movement - Remote Desktop Protocol”, which can be found here https://www.thedfirspot.com/post/lateral-movement-remote-desktop-protocol-rdp-event-logs. During that blog, we discussed how to investigate lateral movement during incidents from the Windows Event Logs and the various dedicated event logs and event IDs that one might use to find the originating system, outbound connections to other hosts over RDP, sessions, and more.
During Part 2 of the blog, we’ll focus more on the artifacts that you might come across when investigating this type of lateral movement! Now, it goes without saying that during investigations, you shouldn’t rely on one artifact but rather, use these artifacts (both event logs, artifacts, and others) to tell the whole story. As you continue to piece together your timeline, having different artifact sources can add weight to your overall analysis in terms of accuracy and confidence, as well as potentially providing another avenue of analysis that may have otherwise been missed or possibly even deleted/tampered with by a Threat Actor (TA)!
WARNING: There is a lot of reading in this writeup, so buckle in and take notes!
The Rundown
On top of events found within various Windows Event Logs, there are artifacts created on both the target and source system when an RDP session is established
Although more difficult than Event Log clearing, artifacts can be deleted or overwritten by a TA or by the system
Artifacts of execution, such as UserAssist, RecentApps, Jumplists, Prefetch and other artifacts, such as Shimcache or Amcache may leave evidence that a system connected via RDP or that RDP was used to establish an outbound connection
There are specific items that can be found in Windows Event Logs that you might not come across within system artifacts such as Prefetch
Note that many of the timestamps associated with these artifacts may not determine how long a session was established for or when it was disconnected
Look for evidence of execution referencing ‘mstsc.exe’ on the source system and ‘rdpclip.exe’ and ‘tstheme.exe’ on the target system.
Evidence of mstsc.exe may indicate that a user attempted to execute RDP
Evidence of rdpclip.exe and tstheme.exe may suggest that the host saw an RDP connection
As a note, throughout this blog I’ll show screenshots from both a forensics package and my live system. The purpose of this is to show that the files exist. You’d ideally want to be conducting this analysis through a forensics image, such as a full disk image or triage capture. Additionally, navigating to these artifacts on a live host may cause unnecessary noise and potentially cause the artifacts to roll-over or provide inaccurate timestamps.
With that said, let's dive right in! As mentioned earlier, the idea of having numerous artifacts that may show the same thing (such as Windows Event Logs - Terminal Services Local Session Manager and Prefetch), is to have additional data sources if logging is disabled, tampered with, overwritten, or artifacts are deleted; always think outside the box! If you check Windows Event Logs and find that the TA cleared these (which is very simple to do) and log forwarding isn’t enabled, there may be other artifacts that you can use that may suggest an interactive RDP session was established! You can then use other artifacts, such as user sessions, firewall logs, other network-based logs, SUM UAL or others to then tell the story of who connected, from where, for how long, what did they do, and where did they go.
So enough on why this is so important from an analysis standpoint, let’s talk artifacts here!
Although I won’t go into granular detail regarding each artifact, this is a high-level blog that I wrote that talks about why these artifacts are important when it comes to a DFIR investigation https://www.thedfirspot.com/post/windows-artifacts-for-intrusion-analysis-a-treasure-trove-of-evidence
During the discussion below, we’ll define “target system” as the system that was RDP’d to and was logged into by an actor.
“Source system” will be defined as the system that established the session outbound to connect to a target.
RDP Bitmap Cache (target system)
As a note, I wrote a previous blog post on this artifact, which can be found here https://www.thedfirspot.com/post/rdp-bitmap-cache-piece-s-of-the-puzzle
This is a fantastic artifact that has become more and more popular over the last few years! This artifact is created when an interactive RDP session is established and can be found on the target system. If you’ve read my other blogs, you’ll always hear me rant about how Windows Artifacts that are created and used during DFIR investigations aren’t there specifically for investigations; they each hold a purpose on the Operating System for efficiency, logging, etc. However, we can use them to our advantage! Bitmap cache definitely falls into this category! This artifact is created when an RDP session is established and it will attempt to “cache” or save common images in an effort to make the RDP session run smoother. From a forensics perspective, not only does the existence of this artifact suggest that an RDP session was established, but it stores small “pixel” images in a tile format from that RDP session! Granted, you’ll need to use tools to piece together these images that were observed during the session, but that can be done with a number of techniques!
The point of this artifact during an investigation is to possibly show you or give you small pieces of what may have happened during that RDP session. Did the user browse sensitive files/folders? Well, Bitmap Cache may have grabbed an image of that! Was the TA running suspicious tools or a command shell such as Command Prompt or PowerShell? Maybe Bitmap Cache grabbed an image of that and you might be able to see commands they were running and their results!
On newer systems, this can be found here ‘Windows 7+
%CURRENTUSER%\AppData\Local\Microsoft\Terminal Server Client\Cache\’bcache##.bmccache####.bin
UserAssist (source system)
As of the writing of this blog post, I don’t yet have a post on UserAssist, but this is a fantastic and reliable artifact of execution! Essentially, this artifact exists to track user execution of GUI-based applications and stores information about that application that may be used by the Operating System, such as how long it was the main application in focus for, how many times it was executed, how many times it was brought into focus as the main application, and last executed timestamp. The unique thing about this artifact is that it's in ROT13 format, meaning each character of the application name is rotated 13 characters in the alphabet. Why is this? Who knows! The Windows Registry is a bit different than other parts of the OS and it's up to the developer of the key to choose the format such as timestamp format, data included, naming convention, etc. It can be the Wild Wild West!
When RDP is executed, or more commonly tracked ‘mstsc.exe’ Microsoft Terminal Services Client, UserAssist generates an entry for ‘mstsc.exe’, which will give you the last execution time, how long it was in focus for, how many times it was executed, etc. A clear indicator that ‘mstsc’ was at least executed, though it doesn’t mean that a session was successfully established on the target system (you’ll need to use complimenting artifacts and timelining to better support that theory).
Well, how do we know who the user is that executed this? That’s an easy one! The UserAssist artifact is found within a Registry Hive! Specifically, the NTUSER.dat for a user. So if it’s found within Johnny Smith’s NTUSER.dat hive, then Johnny Smith executed this! Simple, right?
This artifact can be found within the home directory of the user in question.
For example,
C:\Users\JohnnySmith\NTUSER.dat
Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist Note that you’ll ideally want to use a tool such as RECMD.exe by Eric Zimmerman to collect these hives in bulk, or any similar tool (there’s a ton, but the idea is you probably don’t want to analyze each user’s hive one by one, unless you’re only investigating a single user).
RecentApps (source system)
This artifact is used by the OS to track… You guessed it! Recently Used Applications! Have you ever opened up your Start Menu and noticed that the last application you executed (or a few) are at the top of the list? Well.. that’s being tracked by the OS for convenience so that the apps you use the most are easier to find! Because of this, this artifact tracks application execution.
By reviewing this artifact, you’ll likely see ‘mstsc.exe’ listed here with its last execution time, how many times it was executed and possibly even the destination within its subkeys! Useful!
This artifact can be found in the NTUSER.dat Registry Hive of a user (note this key may look different on a live vs offline host)
HKCU\Software\Microsoft\Windows\Current Version\Search\RecentAppsJumpLists (source system)
The classic Jumplist artifact! This artifact is another extremely useful artifact to show multiple actions, such as file/folder interaction and execution! In a nutSHELL (it’s a shell item, see what I did there?), this artifact contains LNK (shortcut) files of applications!
For this.. You guessed it! You’ll want to look for entries of ‘mstsc.exe’ (see the trend here?). The great thing about this artifact is that it will often grab the target IP address, so you can get an idea of where the user was attempting to connect to! Keep in mind that Jumplists will often have multiple timestamps such as source and target. This is due to the fact that the artifact is a “shell” item, meaning it stores information about other items. So the Source timestamp may be the timestamp of the Jumplist file itself and the Target may be the timestamp of the file being referenced.
This artifact can be found here. Note that Jumplists are found within the user folder of a user in question, which can be used to identify which user initiated the interaction.
C:\Users\<Username>\AppData\Roaming\Microsoft\Windows\Recent\AutomaticDestinations\Prefetch (both source and target system)
Ooooo our first source and target system?! Interesting! What exactly does this mean? Well, simply it means that the artifacts mstsc.exe, rdpclip.exe, and tstheme.exe (mentioned in The Rundown of this blog) can be found within Prefetch, varying on the artifact. Keep in mind that parsing the Prefetch files will yield additional information.
Want to learn more about Prefetch? Check this out! https://www.thedfirspot.com/post/artifacts-of-execution-i-know-what-you-did-last-incident
Essentially, Prefetch is built into Windows in an effort to pre-load code for applications that are executed so that the next time you execute it, it runs slightly faster by loading this common code. It’s PREfetching the code for you!
Let’s start with the Source system. If you haven’t guessed the trend here yet, you’ll be looking for the existence of ‘mstsc.exe’ within Prefetch! That is a strong indicator that a user executed RDP! Note that Prefetch does not list the user that initiated the execution, but with timelining or even pairing this with other artifacts, you’ll have a strong narrative of which user likely executed this (based on login sessions, surrounding activity, etc.)
Now for the first time in this writeup, let’s discuss what you’d see on a target system!
Referencing The Rundown section mentioned earlier, you’ll likely see evidence of rdpclip.exe and tstheme.exe within Prefetch.
The existence of rdpclip.exe is a great indicator suggesting that an RDP session was established on that host. This is used to allow the system Clipboard to be integrated into that RDP session.
The other item you’ll want to look for within Prefetch is the existence of ‘tstheme.exe’. This will handle the “theme” of the RDP session.
Of course, Prefetch can be found here
C:\Windows\Prefetch\ Specifically, you’ll want to look for
mstsc.exe-{hash}.pfrdpclip.exe-{hash}.pftstheme.exe-{hash}.pfShimcache/Amcache (source and target system)
NOTE: These are not artifacts of execution, but may suggest the file at least had presence on the system. Other artifacts should be paired with these to have a better understanding of execution)
Want to learn more about Shimcache and Amcache? Look no further than here! https://www.thedfirspot.com/post/evidence-of-program-existence-shimcache and https://www.thedfirspot.com/post/evidence-of-program-existence-amcache
Shimcache is primarily used for application compatibility. It will attempt to scan applications to determine if the application requires “shimming”, which essentially means adding code/calls that will help in running on a different architecture. The issue with this artifact is that it has now been proven that Shimcache will attempt to shim an application just by viewing the filename within Windows Explorer, meaning that if the file is observed within Explorer, it will get a Shimcache entry. Note that Shimcache timestamps are the last modified timestamp of the executable itself, not when it was executed and not when it was “shimmed”.
Amcache has a very similar purpose in the sense that it's used by the OS to track applications and information about them. Such as their version, author, install date, etc. Much like Shimcache, Amcache can create entries for files without the user executing them. This is due to a scheduled task running that will automatically look for newly added drivers, programs, etc.
However, both of these may have indications of the existence of ‘mstsc.exe’, ‘tstheme.exe’, and ‘rdpclip.exe’. Although there are other artifacts that will more concretely prove execution, this can still be a great source for surrounding context/support.
Shimcache can be found within the SYSTEM registry hive here
%SystemRoot%\System32\Config With the key path of
SYSTEM\CurrentControlSet\Control\SessionManager\AppCompatCache\AppCompatCacheand Amcache can be found within its own dedicated hive called ‘AmCache.hve’ found here
%systemdrive%\Windows\AppCompat\Programs\AmCache.hve
Terminal Server Client Registry key (source system)
This is a fantastic registry key that can contain information about target hosts that were connected to from the source system. Again, note that the existence of these keys does not indicate the connection was successful.
The existence of hostnames and IP addresses within this key are an indication that an RDP connection was attempted. If you see hosts/IP addresses here on a host you’re investigating, you might want to isolate and investigate them as well!
This can be found here
NTUSER\Software\Microsoft\TerminalServer Client\Servers. 
Note that this is located within the NTUSER.dat Registry Hive of a user. With this said, the user hive you’re reviewing will be the user that attempted these connections.
BAM/DAM (source system)
This is the Background Activity Monitor and Desktop Activity Monitor artifacts. Although less common, these can still be a great source of information to look for evidence or entries containing ‘mstsc.exe’ and may have a timestamp with the first execution time.
This artifact is located within the SYSTEM registry hive
SYSTEM\ControlSet001\Services\bam\State\UserSettings\{SID}
Default RDP File (source)
This is a default file created once an RDP connection has been attempted. It can record the last and first time an RDP connection was attempted as well as the target hostname, found within the default.rdp file when editing it.
This is located within
C:\Users\<username>\Documents\Default.rdp As you can see, there are a decent amount of artifacts that can be reviewed to determine if RDP was executed from a system of interest and if a host we’re investigating was RDP’d to from another host! Pair these artifacts with others and you’ll have a great timeline indicating lateral movement via RDP. Keep in mind that lateral movement can be conducted through a number of other techniques/tools, but TAs LOVE to use RDP! Why? Because it’s already built into the OS and you probably don’t have great controls surrounding it! You’re admins are probably using this on a day-to-day basis, meaning the TA has more of a chance to Live Off The Land (LoTL) and stay undetected!