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

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988  
Read more

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

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog that a
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c
Read more