This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
As long as there is one ClipboardChange rule active, Sysmon seems to log all clipboard activity to the Archive folder.
Tested version: noticed in Sysmon64 12.02, same behavior in Sysmon64 13.01
Sample config:
<RuleGroup name="" groupRelation="or">
<ClipboardChange onmatch="include">
<Image condition="image">windowsterminal.exe</Image>
</ClipboardChange>
</RuleGroup>
With this config, Sysmon logs EventIDs 24 as expected when I copy data from a Terminal window, and nothing outside of that. However, the Archive folder gets filled with all kinds of clipboard events happening outside of Terminal.
Playing with the "CaptureClipboard" configuration entry doesn't seem to change anything.
Is this expected behavior?
Beyond that, would it be possible to have a configuration setting where clipboard events get logged to the evtx log, without writing the actual data to the Archive directory?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 35%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ED%3C/text%3E%3C/svg%3E)
Just another sysmon user here.
I can produce this behavior as well and agree that it is unexpected and undesirable.
Clipboard content of images not listed in include rules of my active sysmon config are ending up in the archive. There are no corresponding events in the event log.
I am very concerned about the accumulation of secrets like passwords and access keys in this archive. Personally, I would like to be able to control what gets archived or logged not only by image and hash but also by patterns in content via include/exclude rules which accept regular expressions.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(147.20000000000002, 79%, 24%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDM%3C/text%3E%3C/svg%3E)
I think I'm seeing this too. I actually hadn't specified any include filter for ClipboardChange events because I'm not interested in them right now. But over several weeks my C:\sysmon directory filled up over 400 GB of files which appear to be clipboard buffers.
@Dave McCormack - Can you confirm the version and config producing that behavior?
My observation in the current version of sysmon (v13.01) is that the undesired behavior (CLIP files archived) can be prevented when ClipboardChange rules include nothing.
I'm running Sysmon 13.01, and my config specifies <ClipboardChange onmatch="include"/>.
I completely cleared out my C:\Sysmon directory yesterday but it has already accumulated over 14,000 files taking up over 8 GB of space. But now that I look at it again, I don't think these are saved clipboard buffers. There are simply too many of them. I have no idea where these are coming from. They can't (or shouldn't) be deleted file backups because my config does not specify the CopyOnDeletePE value and it defaults to False.
Do the file names in the archive have a prefix of "CLIP-"? If not, the only other source of files in archive would be deleted files detected via FileDelete rules. It stands to reason that FileDelete rules have the same bug as ClipBoard rules and that all deleted files are getting archived if any FileDelete rules exist. That said, I thought the FileDelete archive behavior was corrected in v13 and am presently unable to reproduce the the undesired behavior. My test plan does not include additional factors such as CopyOnDeletePE.
I've forwarded this Q&A discussion link to the development team at syssite@microsoft.com for awareness.
Thanks. My files don't have the "CLIP-" prefix so I guess they are backups of deleted files (I have FileDelete rules). I'm surprised that this backup occurs by default when a FileDelete rule is present. I'd have thought it would be possible to have a FileDelete rule without getting a backup.
All good! I'd like to to have the option to disable archive in general so I am looking forward to an authoritative response to a related Q&A thread.
This also happens with FileDelete rules and support for distinguishing between what gets archived and what just gets dropped is planned for a future release.