How to Perform Clipboard Forensics: ActivitiesCache.db, Memory Forensics and Clipboard History

 


During a compromise, threat actors often copy-paste data to the clipboard – usually credentials, PowerShell commands or IPs. When it comes to malware, infostealers, RATs and keyloggers often monitor what is being stored in the clipboard (as it may contain cryptocurrency seed phrases, passwords, and interesting data). 

Incident response analysts also rarely perform forensic examination of clipboard data due to the transient nature of the data residing in volatile memory and setting prerequisites. However, with the advent of the latest Windows updates, depending on how the system is configured – historical clipboard data may be stored on the system for analysis. This should be considered the next time an analyst is performing forensic analysis of a system. 

Forensic considerations when analysing clipboard data:

  1. What time did the threat actor copy data to the clipboard?

  2. Where did the threat actor copy data to the clipboard from?

  3. Was the data ever pasted (on the same system) or just copied? 

Scenarios when clipboard forensics is necessary:

To demonstrate the importance of analysing clipboard artefacts – here are some real-life examples where knowing the clipboard data may have helped an engagement:

  • Signs of RDPCLIP.exe being executed as it supports the use of clipboard during RDP sessions

  • Ransomware engagements where AnyDesk and TeamViewer logs reference clipboard data

  • Malware (typically RATs, infostealers or keyloggers) leveraged by commodity groups and APT groups that hooks into API calls like OpenClipboard() and GetClipboardData(). 

  • Other incident response engagements where threat actors may be coping credentials / commands during sessions

This blog post explores three methods to forensically examine clipboard data – the first method being an artefact on disk, the second through forensic examination of RAM and the third being a folder that’s resident on disk which stores data. 

Detection Method 1: ActivitiesCache.db

The artefact ActivitiesCache.db has started to log clipboard activity since Windows 10 version 1803. (If you are not familiar with this artefact it is immensely useful during an investigation as it tracks several things like program execution. It will even tell you down to the detail where a program i.e. notepad.exe was used to open a file called “file.txt”).

If you’re interested in reading more about ActivitesCache.db I recommend you check out the following blog posts and write-ups:

Step 1: Check the system has clipboard history and sync enabled

The prerequisite for clipboard data to be logged by this artefact relies on the system having two settings checked:

  • Clipboard history enabled 
  • Clipboard sync across devices 

A screenshot of this can be seen below:


Step 2: Locate the database file for analysis 

The location for the artefact is in the following directory:
%AppData%\Local\ConnectedDevicesPlatform\<UserProfile>\

There are three files within this folder which can all be analysed as a part of this investigation:
  • ActivitiesCache.db (the database file that we can analyse)
  • ActivitiesCache.db-shm
  • ActivitiesCache.db-wal (the write-ahead log which can also be analysed for data)  


When you load up the database into your database browser (I’m using DB Browser for SQLite) check out the “SmartLookup” view. Otherwise – you can still see the data in the table named “ActivityOperation” with the column name “ClipboardPayload”. 

The forensic information most interesting to us is:
  • StartTime (epoch time) – When the data was first copied to the clipboard 

  • ExpirationTime (epoch time) – When the data will be deleted from the ActivitiesCache.db (roughly 12 hours) 

  • ClipboardPayload – Base64 encoded string of the clipboard contents  

  • Payload – This field tells you where the clipboard data was copied from! 

  • ActivityType – Type 10 means data resides in clipboard, Type 16 shows if data was copied or pasted


For this blog post, I created a notepad and wrote some text in it, which I then proceeded to do a “copy” operation (aka copying something to clipboard). All that is required for this table to be populated with clipboard data is a “copy” operation. 


Step 3: Look for any entries showing clipboard activity

There are two activity types to note regarding clipboard data – type 10 (which shows clipboard operation occurring) and also type 16 which details if it was a “copy” or a “paste” operation. 

Filtering for type 10, I can see there were several clipboard activities occurring on my system: 

Step 4: Filter for the relevant entries and determine where the clipboard data was copied from 

By filtering by the epoch time (column StartTime) relevant to the investigation – I was able to isolate one relevant clipboard activity. Don’t forget to also filter and pay attention to the “payload” column – you’re able to distinguish the exact file where the clipboard data was copied from! 

In the screenshot below, you can see that the data that I copied came from a file on my Desktop named “asdasdasd.txt”. 




Step 5: Determine what was copied into the clipboard

The data in the “ClipboardPayload” column is just base64 encoded. Decoding this will reveal the contents stored in the clipboard. As you can see I wrote myself a love note. 


Step 6: Determine if the data was ever pasted back onto the system 

By filtering “ActivityType” by type 16, you’ll be able to observe if there was ever a “paste” operation – or if the data was only copied. As you can see in my instance, the data was only ever just “copied”. 



Detection Method 2: Memory Forensics 

Clipboard data is stored in the tagCLIPDATA structure and can be pulled through memory analysis. The data will always be in text format. 

The original whitepaper that highlighted the technique to pull clipboard data from memory is this excellent whitepaper “Extracting the Windows Clipboard from Memory” which was also presented by the authors at the Digital Forensic Research Conference.

The logic to pulling clipboard data lies in looking for tagCLIP structures and then associating the “hData” field with their corresponding tagCLIPDATA value. The “hData” field corresponds to a handle value for the tagCLIPDATA object. Luckily, Volatility has already pre-built this into a plugin named “clipboard”. Here’s an example of this being utilised:


Detection Method 3: Clipboard History Folder

Finally, if clipboard history is enabled a folder path will be created storing clipboard data. The location for this is:
%AppData%\Local\Microsoft\Windows\Clipboard

This detection method was covered by @PhillMoore in his blog post here (https://thinkdfir.com/2018/10/14/clippy-history/). The data will be stored in JSON and will reveal the data that was copied along with the timestamp. The two folder locations to review are:
  • Pinned 
  • HistoryData
It's important to note that with this artefact there are some restrictions:
  • Clipboard history will only store clipboard text that is under 4MB per text
  • Clipboard history will also save HTML and bitmaps (not just text) whereas the ActivitiesCache.db only stores text format
  • Clipboard history will only store 25 entries 
  • Clipboard history is cleared whenever you restart the system 

References 
https://kacos2000.github.io/WindowsTimeline/WindowsTimeline.pdf
https://cellebrite.com/en/exploring-the-windows-activity-timeline-part-3-the-value-of-clipboard-content/?utm_content=134912769&utm_medium=social&utm_source=twitter&hss_channel=tw-209890844
https://www.researchgate.net/publication/251702413_Extracting_the_windows_clipboard_from_physical_memory
https://thinkdfir.com/2018/10/14/clippy-history/



Comments

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Successful 4624 Anonymous Logons to Windows Server from External IPs?