No, this isn’t a post about Clippy, sorry everyone, especially Lee 🙂 Clippy’s gone forever.
Win10 October update (version 1809) introduced clipboard history!
This allows users to store their copied items (pictures and text so far, including formatting) in a list. There is also the ability to pin items and synchronise your history between devices. I did a brief amount of testing to see what forensic artefacts I could find on a single system. I haven’t had a look at synced clipboards just yet, but if someone does, let me know and I’ll add the link to the bottom of this post
In settings, you can turn on the clipboard history, enable sync with your Windows account, and clear data. I don’t know much about the sync option, but I imagine if your employees are copying sensitive data you might not want it to be left on other devices that they’ve logged into. That being said, the data is encrypted at rest.
If you press Win+V you can load up the clipboard history. Any text or pictures that you’ve copied will get placed at the top of the stack, and if you click on any one of them they’ll get automatically pasted and set as the current clipboard item. Selecting an item off the list doesn’t move its position in the list, and I haven’t explored whether there’s any record of selecting/pasting an item from the list.
In my test, I saved “hello world” to the clipboard.
As shown, the item and the time it was added is indicated. There’s also the option to clear the item from the list, pin it for later on, as well as clear the whole list.
As soon as I did that, with history turned on, “C:\users\forensics\appdata\local\microsoft\windows\clipboard” was created. Imagine theres a registry value updated to indicate that you’ve turned on the history, but I haven’t looked for that.
The “Clipboard” folder has “HistoryData” and “Pinned” folders within, and both are empty save a folder named with a GUID. I would have thought that “HistoryData” would contain the list, but that may only be populated if sync is enabled. That’s my guess at the moment without testing.
Pinned, however, is an easier test. I pinned an item, and some data was populated in the Pinned folder as expected.
There’s a GUID within the Pinned folder and within that there’s another GUID for each pin. The created time of the folder indicates when it was pinned.
As shown above, I pinned two items to the list.
The metadata.json above shows each item and the timestamp corresponds to when the item was pinned to the list. These items were created locally, I imagine if they were synced it would be indicated in the “source” item, maybe even telling you where they were synced from.
Opening up the folder for the first item that I pinned there are three files. Why they save the filenames base64 encoded I have no idea.
I’ve only seen three unique strings though which makes things a bit easier:
- Locale – TG9jYWxl
- Text – VGV4dA==
- Bitmap – Qml0bWFw
(Sidenote: Locale doesn’t always show up. I pinned an item copied from Edge and Mail and it wasn’t there. But I pinned an item copied from Chrome and it was. ¯\_(ツ)_/¯ Windows. Probably something to do with default Windows apps)
The data within these files appears to be encrypted/encoded/otherwise obfuscated. Maybe with a unique key, maybe with a token derived from their login credentials. Considering this is all around synchronisation I’d say its something that’s being shared across multiple devices.
I tried to copy items to populate the “sourceAppId” but haven’t figured that out yet.
If I select a pinned item as the active clipboard item it doesn’t appear to affect the timestamps on any of the files on disk
Unpinning the item removed the folder. I looked at the folder in FTK imager and the folder is gone, not just marked as deleted. You may be able to carve but it wasn’t easily recoverable. When the item is unpinned the metadata.json is also updated.
I’ve copied files and they haven’t appeared in my clipboard, but if you take a screenshot by default this will get copied into your clipboard so it will be stored in your history too. Something to be aware of from a security perspective, but may also be useful for DFIR folks.
This was super helpful though because it helped me identify the process where the clipboard history was stored. I basically opened task manager and hit print screen until the relevant svchost.exe bubbled to the top. Every time I hit print screen it got a bit bigger, so I was confident I could examine that for more information.
Rather than dumping all of memory, I used Magnet Process Capture to extract my specific process and then ran both strings and a photo carver to look for my history.
I had copied a URL from Edge and did a string search for it
I also ran the dumped process through a couple photo carvers (AXIOM and PhotoRec) and was able to extract all of the screenshots that I had taken. They were all extracted out as bitmaps.
Whilst in memory, the history doesn’t appear to be encrypted. I looked at the strings surrounding the URLs, hoping to find references to Edge, but I didn’t see anything helpful. Someone with more experience pulling apart memory data structures might have more success.
I did copy my username and password using the Lastpass copy features and as expected they both appeared in my history. The autofill/autologin didn’t load into the history, however.
Lastly, I signed out of my current user and signed into another account. Signing out cleared the clipboard from the UI, however if I remained logged in and switched to another user it remained populated. Similarly, restarting the machine cleared the history. Any pinned item remained as expected.
If anyone has done any more work on this, especially updating the existing clipboard volatility plugin let me know. I don’t know how useful this might be for examiners, but you never know what someone might have copied!
Vico Marizale has done some additional research on this topic! At the time I didn’t look into the syncing feature, but because of this I took a very quick look at the pinned items again.
I opened up a pinned item in Nirsoft’s DataProtectionDecryptor and it seems to have “decrypted” the data, but saving it out and removing the DAPI header didn’t seem to result in a bitmap.
But apparently the data is encrypted with the newer version of DPAPI; DPAPI-NG. So now to find a tool to decrypt that!