Insider Threat Matrix: RDP Clients
Within our test environment, which we’ll showcase later, you’ll see the malicious use of RDP in a simulated enterprise setting. In our Insider Threat Matrix (ITM) Framework, we note that RDP can be used to move laterally across networks. However, this tool can also facilitate data exfiltration, often bypassing common detection methods.
RDP is installed by default on all Windows computers, and only administrative accounts can establish a Remote Desktop connection. If a standard user needs access, they must be added to the Remote Desktop Users group. This raises the question: why would a regular user need RDP access?
Setting the Environment: Scenario, Triage Collection, and User Behavior Analysis
In our case study, we consider that Midnight Blizzard used RDP to view files, and directories, and install malware and tools to maintain access even after the RDP session ended—actions that leave substantial evidence for investigators. To better grasp the concept let’s imagine the scenario below:
"Meet Cerulean Inc., a respected manufacturer of industrial control systems. Recently, they became a target of phishing emails disguised as offers for remote support. A high-profile employee, Jane Andrada, reportedly fell for an RDP scam.“
Let's examine the triage image to look for potential signs of data exfiltration or indicators of compromise (IOCs). To streamline our findings, we’ll be using the Magnet AXIOM Process tool.
Let's import the KAPE Triage folder for examination and review its contents in Magnet AXIOM Examine.
This process will take a few bits.
In the Cloud Services URLs tab, you’ll notice multiple references to Google Drive. Notably, these appear after the RDP session (which I’ll demonstrate shortly), making this activity highly suspicious. We label this as Exfiltration via Cloud Storage in our Insider Threat Matrix (ITM). It’s a clever tactic by the attacker, especially if the drives are shared.
The RDP session occurred on 11/05/2024 at 9:00:03 PM UTC, with Jane based in London, Europe, for context. As previously mentioned, I’ll provide full evidence of this later. Take a closer look at this artifact: Google Searches. You can see the threat actor searching for other cloud-based storage platforms on Jane’s device. These platforms often support SSO, making it convenient to log in, further indicating signs of exfiltration.
Our previous findings reveal some unusual activity on the user’s endpoint. Let’s continue our investigation by drafting a hypothesis to guide our hunt.
Hypothesis #1:
“If the attacker accessed Jane’s PC through RDP, why are there so few local files accessed? This might explain why they started looking for files in the cloud. Noticing the file 'New Project.PNG'—it was accessed around the start of the RDP session, and it’s the only file accessed at that time.“
Just a note: the timestamps in the right column (two columns right from Path) are shown in local time, so there’s a time difference. Remember, Jane is in British Standard Time (BST).
Further investigation showed that Jane had the Slack desktop app installed on her computer through Magnet Examine’s “Rebuilt Desktop” module. Interestingly, the company officially uses Teams as its primary communication tool—a definite red flag, indicating some Shadow IT at play.
This raises even more questions:
- What kind of communications are happening on Slack?
- Are there any useful clues?
- Could the threat actor be aware of its presence?
Speak of the devil! Look at what Axiom uncovered in the browser history: evidence of chat activity. It seems these chats occurred about an hour before the RDP session. We also found a Slack workspace named Cerulean Inc (which isn’t an official workspace). This raises questions, and from here we can formulate our hypothesis.
Hypothesis #2:
“Sensitive information may have been shared or discussed in Slack chats on the unofficial Cerulean Inc workspace, especially since Jane’s Google Drive and desktop files were empty. If the attacker accessed these chats, they might have gained valuable information for further exploitation.”
Here's something worth noting: it appears she’s using her email on her workstation—a definite red flag, right?
This is getting interesting! We found evidence of not only chrome.exe and slack.exe activity after the RDP session but also rdpclip.exe. This program manages clipboard sharing during RDP sessions, enabling easy copying and pasting of text and files between the local computer and the remote desktop. The SRUM feature helped us uncover this crucial information, as it stores data about system and application resource usage.
Interestingly, it seems either the sysadmin overlooked this or Jane somehow gained local admin access on her workstation. This would explain how she was able to download Slack—a non-approved app—onto her system. Just to clarify, she’s the Head of the Production Department, not an IT administrator. Something strange is going on.
Here is the initial timestamp for the RDP session on Jane’s PC. The IP address is redacted to protect the identity of the threat actor (me). Event ID 1149 confirms a successful login via the Remote Connection Manager, while Event ID 25 logs reconnected sessions, and Event ID 24 logs disconnected sessions.
Identifying Data Exfiltration
Hypothesis #3:
“The attacker likely exfiltrated sensitive data, including high-profile documents, from the Slack channel and saved them to their drive.“
Given the challenges in tracking files transferred via RDP, identifying concrete evidence may be complex and require advanced forensic techniques. However, files containing the word 'slack' followed by a file name could serve as key indicators of successful data exfiltration.
Here are a few key points:
- “RDP sessions can allow threat actors to access resources and files from a remote system, which may not leave traces in the local user’s data.”
- “If the files were downloaded through a Slack file sharing or messaging integration, that could bypass the typical local download mechanisms and not get recorded in the user’s standard download history“
- “The Windows Defender logs may have been capturing the file activity from the remote session on Jane’s account, despite local user data ($MFT) not reflecting the downloads.“
These points explain why the file paths are present in the logs, even though there are no signs of the files in the local user’s download or browsing history (i.e., Jane’s Chrome artifacts). In this case, the remote access and alternate file transfer method did not generate those typical user-level records, leaving blindspots for investigators who rely on a piece of artifact rather than complementing it with others.
The evidence was found in Windows Defender MP Logs, an artifact often neglected but useful in battling RDP-based exfiltration.
C\ProgramData\Microsoft\Windows Defender\Support
Conclusion
If you found this topic interesting and you don’t have any exposure to Malware Analysis, Reverse Engineering, Digital Forensics and Incident Response, why not take a look at our gamified blue team training platform, where we have prepared a lab titled Cerulean that lets you respond to this type of Insider Threat investigation.
