Sysmon 13.01 - possible bug in ClipboardChange behavior

Question

Sysmon 13.01 - possible bug in ClipboardChange behavior

ZeArioch 31

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?

dstaulcu 351 Reputation points

2021-02-12T14:38:41.9+00:00

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.
Dave McCormack 11 Reputation points

2021-02-18T09:20:54.42+00:00

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.
dstaulcu 351 Reputation points

2021-02-18T15:31:14.733+00:00

@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.
Dave McCormack 11 Reputation points

2021-02-18T15:55:05.803+00:00

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.
dstaulcu 351 Reputation points

2021-02-18T16:08:22.677+00:00

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.
Dave McCormack 11 Reputation points

2021-02-18T18:48:54.04+00:00

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.
dstaulcu 351 Reputation points

2021-02-18T19:04:18.443+00:00

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.

https://learn.microsoft.com/en-us/answers/questions/264534/sysmon-1301-prevent-archivedirectory-creation-and.html

Answer accepted by question author

0 additional answers

Your answer

dstaulcu 351 Reputation points

2021-02-12T14:38:41.9+00:00

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.
Dave McCormack 11 Reputation points

2021-02-18T09:20:54.42+00:00

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.
dstaulcu 351 Reputation points

2021-02-18T15:31:14.733+00:00

@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.
Dave McCormack 11 Reputation points

2021-02-18T15:55:05.803+00:00

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.
dstaulcu 351 Reputation points

2021-02-18T16:08:22.677+00:00

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.
Dave McCormack 11 Reputation points

2021-02-18T18:48:54.04+00:00

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.
dstaulcu 351 Reputation points

2021-02-18T19:04:18.443+00:00

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.

https://learn.microsoft.com/en-us/answers/questions/264534/sysmon-1301-prevent-archivedirectory-creation-and.html

Answer 1

Alex Mihaiuc 736

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.

0 comments