Clipboard History Forensics in ActivitiesCache.db

TL;DR. Clipboard content is activity type 10: Base64 text in ClipboardPayload, kept for 12 hours. Copy and paste events are type 16, with Group = Copy or Paste and a clipboardDataId linking them. Type 10 was reported only when Clipboard history and cross-device sync were both on, so most databases have none. When it is there, it is gold: commands, paths, sometimes credentials.

Clipboard evidence is rare in Timeline. That is exactly why it is worth knowing cold: when it shows up, it tends to answer the question the rest of the case only circles around.

The two activity types

kacos2000 first observed type 10 on a Windows 10 1809 Insider build and noted he had only seen clipboard text; images did not sync the same way at the time (kacos2000).

When clipboard content is recorded

inversecos reports two prerequisites for clipboard logging in ActivitiesCache.db: Clipboard history enabled and clipboard sync across devices enabled (inversecos). Neither is on by default in most environments, which is why type 10 rows are uncommon.

Where to check the settings:

Read user hives with the registry parser. Keep in mind that Microsoft stopped cloud syncing of activity history for Microsoft accounts in 2021 and for Entra ID accounts from January 2024 (Microsoft Support). How that interacts with local clipboard rows on current builds is not documented; test on your own images rather than assume.

Decoding ClipboardPayload

The column holds a JSON array. Each element has a Base64 content and a formatName:

[{"content": "cmNsb25lIGNvcHkgRTpcZXhmaWwgbWVnYTpmaW4tYmFja3VwIC0tdHJhbnNmZXJzIDg=", "formatName": "Text"}]

Decoding the Base64 gives the text. inversecos puts it simply: the data is "just base64 encoded" (inversecos). The example above, from this site's fictional sample, decodes to an rclone copy command.

The Windows Timeline Parser decodes ClipboardPayload on every row that has it, tries UTF-8 then UTF-16LE, strips trailing NUL characters, and joins multiple text elements. The result is shown in the table, flagged Clipboard, searchable with the text filter and exported in the ClipboardText CSV column. ClipboardPayload in the glossary has the short version.

Attacker-controlled text is dangerous in a spreadsheet. The tool's CSV export prefixes cells that start with =, +, - or @ so a copied formula does not execute when the analyst opens the export.

Reading copy and paste events

Type 16 rows do not hold the text, but they tell you the direction and the app:

1. Filter on Copy / paste.
2. In the JSON export, read group (Copy or Paste) for each row; open the row to see the clipboardDataId in the payload.
3. Match a Copy and a Paste with the same clipboardDataId: the first app is the source, the second the destination (kacos2000).
4. If a type 10 row exists for the same item, you have the content as well.

This is how "the user copied a path from Notepad and pasted it into a console" becomes a sequence you can show rather than infer.

What clipboard rows can reveal

In real cases, clipboard text tends to contain what users do not type twice:

Handle it as sensitive material: redact credentials in reports, and restrict access to the export.

Clipboard triage in five minutes

A routine that works on any collection, whether or not you expect clipboard data:

1. Load every user's database with its WAL into the Windows Timeline Parser and read the Clipboard items counter. Zero is an answer too: write it down.
2. Filter on Clipboard. For each row, note the source app, the time in UTC and the decoded text. Check the Only in WAL flag: clipboard rows are short-lived, so the newest ones are often WAL-only.
3. Filter on Copy / paste and line up events around each clipboard row. A copy in Notepad followed by a paste in a console within seconds is a sequence worth a sentence in the report.
4. Search the decoded text for hosts, shares, URLs and account names, then pivot: the same strings may appear in event logs, browser history or messaging apps.
5. Pull the user hive and record EnableClipboardHistory, so the report explains why clipboard data exists (or does not) on this machine.

Limits

• Rare. Settings-dependent, and the 12-hour lifetime means the window is short.
• Text only in the observations published so far.
• Deleted rows. kacos2000 notes that many expired type 10 entries can be recovered, even months later, and offers carving tools for it (kacos2000/WindowsTimeline). This site's parser shows live rows (checkpointed and WAL) only.
• Other sources. Clipboard data can also live in memory; see inversecos on memory-based clipboard analysis (inversecos) and the RAM parser. Velociraptor has a Windows.Forensics.Clipboard artifact in its exchange (Velociraptor).

FAQ

Does ActivitiesCache.db always contain clipboard history?

No. Clipboard content (activity type 10) was reported only when both Clipboard history and cross-device clipboard sync were enabled, and those entries expire after 12 hours. Most databases have none.

How is clipboard text stored in ActivitiesCache.db?

In the ClipboardPayload column as a JSON array whose content field is Base64-encoded text. Decoding the Base64 gives the copied text.

Can deleted clipboard entries be recovered?

Sometimes. kacos2000 reports recovering expired clipboard entries from the database and its WAL with a carving tool. Standard parsers only show live rows.

Related articles

• ActivitiesCache.db activity types and payload fields
• A Windows Timeline investigation, step by step
• Why ActivitiesCache.db-wal matters