What's on your clipboard?
One of the fascinating aspects of Windows systems, from a DF/IR perspective, for me has been the clipboard. Notice I said, "one of", rather than "the"...that's because there are a lot of fascinating aspects of Windows systems when it comes to DF/IR work. I include the clipboard in this mostly because there is various malware...infostealers, etc...that will dump the contents of the clipboard as part of their functionality. Also, there's malware that will place a malicious bitcoin wallet address on the clipboard, in hopes that the user simply pastes that address when they're enabling a transaction. I mention malware that modifies the clipboard in this 2008 blog post.
I'll admit that early on in my DF/IR career, this isn't something that I thought about collecting as part of an IR engagement. Even when we were using batch files to run native tools from a USB stick or CD-ROM drive, I don't remember including the capability to dump the clipboard, nor even having the discussion to do so. This may be because we weren't seeing anything...any data, or malware analysis...that would indicate that this was something we needed to be concerned about. Even back as far as 2007 or 2008-ish, I don't remember seeing any malware on PCI engagements, for example, that showed any signs of interacting with the clipboard.
However, now, there's even a MITRE ATT&CK technique, T1115, to address clipboard data. The MITRE ATT&CK page for the technique lists more than a few examples of malware and groups that target the Windows clipboard for data.
I recently ran across a reference to a tool that's been around for a while named ClipboardHistoryThief. According to the Github site for the tool, it's been around for about 3 yrs. After reading a bit about the ClipboardHistoryThief app, I decided to take a look at what I might have on my clipboard, so I hit the Windows logo key + V key combo, and the image seen in Figure 1 appeared on my desktop.
![]() |
| Fig. 1: Clipboard History |
My first thought was, whoa, what the...? I hadn't enabled the clipboard history on my system...or had I? Opening the Registry Editor, I tried to navigate to the first key at the above StackOverflow link, but I couldn't complete the key path. Navigating to the HKCU key path, I saw what is shown in Figure 2.
![]() |
| Fig. 2: Registry Editor |
Running the ClipboardHistoryThief tool on my system, I got what you see in Figure 3, which is essentially a replica of what I saw using the key combo above.
![]() |
| Fig. 3: Tool output |
Okay, wow. The tool works great...but why is there a history of data on my clipboard? I went to Settings on my system, searched for "Clipboard" and got what you see in Figure 4. These are the same settings seen in this 2022 blog post.
![]() |
| Fig. 4: Clipboard settings |
So, if ClipboardHistoryThief is able to dump the contents of your clipboard, and not just the last item pasted to the clipboard, but the entire history. If the history is enabled, can you imagine how the attack surface changes and expands? Consider this...bad guy gets in via some means, but it really doesn't matter how. This could be entirely automated...get some code on the endpoint that enables the clipboard history if it isn't already, and then on a regular basis, it dumps and clears the contents of the clipboard, shipping the contents off to a C2 server. This is just a regular feed of data, consisting of whatever appears on the clipboard. What exactly is that? Well, I know I copy-paste contents of emails and documents all the time. For work, as well as on my personal system, I'll copy swaths of text content and paste it to another location in a file, or in another window or document all together. This might include customer-specific information that I'm tracking, or something I'll be redacting prior to inclusion into a blog post.
Overall, this is something I'd be concerned about, from an endpoint auditing perspective. In this 2022 blog post, I mention several Registry locations that you might want to include in system audits, or as part of your incident analysis, that are associated with means of data collection. These locations, which include the clipboard, provide a means for data collection that we don't usually see in incident write-ups or descriptions, and can be used ahead of data staging and exfiltration.
Something else is that within Figure 4, there's an option to "Sync across devices". I can't say that I'm aware of what sort of devices, nor how the devices are connected (Microsoft Live account??), but seeing this setting enabled, particularly if it's against corporate policy to do so, would be concerning.
For example, consider insider threat cases, and how data might be exfiltrated, if all someone has to do is copy content to their clipboard, and the data is sync'd to another device. In such cases, I'd want to look for not only the "Sync" setting, but also for indications of other connected devices.
Introduction to Malware Binary Triage (IMBT) Course
Looking to level up your skills? Get 10% off using coupon code: MWNEWS10 for any flavor.
Enroll Now and Save 10%: Coupon Code MWNEWS10
Note: Affiliate link – your enrollment helps support this platform at no extra cost to you.
Article Link: Windows Incident Response: What's on your clipboard?
1 post - 1 participant
Malware Analysis, News and Indicators - Latest topics



