Sysmon can now write clipboard contents

The release of version 12 of Sysmon was announced on September 17 on the Sysinternals page . In fact, new versions of Process Monitor and ProcDump were also released that day. In this article I will talk about a key and controversial innovation in version 12 of Sysmon - an event type with Event ID 24, into which work with the clipboard is logged.







Information from this type of events opens up new possibilities for monitoring suspicious activity (as well as new vulnerabilities). So, you can understand who, where and what exactly they tried to copy. Below the cut is a description of some fields of the new event and a couple of use cases.



The new event contains the following fields:



Image: the process from which data was written to the clipboard.

Session: The session in which the clipboard was written. This could be system (0)

when running interactively or remotely, etc.

ClientInfo: Contains the username of the session, and in the case of a remote session, the original hostname and IP address, if available.

Hashes: defines the name of the file where the copied text was saved (similar to working with events of the FileDelete type).

Archived: status if text from the clipboard has been saved in the Sysmon archive directory.



The last couple of fields are alarming. The fact is that from version 11 Sysmon can (with the appropriate settings) save various data to its archive directory. For example, Event ID 23 logs file deletion events and can save them all in the same archive directory. The CLIP tag is added to the name of files created by working with the clipboard. The files themselves contain the exact data that was copied to the clipboard.



This is what the saved file looks like
image



Saving to file is enabled during installation. You can set up whitelisting processes for which the text will not be saved.



This is how the Sysmon installation looks like with the appropriate archive directory setting:
image



Here, I think, it is worth remembering about password managers, which also use the clipboard. Having Sysmon on a system with a password manager would allow you (or an attacker) to capture those passwords. If we assume that you know which process is allocating the copied text (and this is not always a password manager process, but maybe some svchost), this exception can be added to the whitelist and not saved.



Maybe you didn't know, but text from the clipboard is captured by the remote server when you switch to it in RDP session mode. If you have something on the clipboard and you switch between RDP sessions, that information will travel with you.



Let's summarize Sysmon's clipboard capabilities.



Fixed:



  • Text copy of the pasted text via RDP and locally;
  • Capture data from the clipboard by various utilities / processes;
  • Copy / paste text from / to the local virtual machine, even if this text has not yet been pasted.


Not recorded:



  • Copying / pasting files from / to a local virtual machine;
  • Copy / paste files via RDP
  • The malware that hijacks your clipboard only writes to the clipboard itself.


For all its ambiguity, this type of events will allow restoring the algorithm of the attacker's actions and will help to identify previously inaccessible data for the formation of post-mortems after attacks. If writing content to the clipboard is still enabled, it is important to record every access to the archive directory and to identify potentially dangerous ones (initiated not by sysmon.exe).



To capture, analyze and respond to the events listed above, you can use the InTrust tool , which combines all three approaches and, moreover, is an effective centralized repository of all collected raw data. We can set up its integration with popular SIEM systems to minimize the cost of their licensing by transferring processing and storage of raw data to InTrust.



To learn more about InTrust, read our previous articles or leave a request in the feedback form .



How to reduce the cost of ownership of a SIEM system and why you need Central Log Management (CLM)



We turn on the collection of events about the launch of suspicious processes in Windows and identify threats using Quest InTrust



How InTrust can help reduce the frequency of unsuccessful authorization attempts through RDP We identify an ransomware



attack, we get access to a domain controller and trying to resist these attacks



What is useful to get from the logs of a Windows workstation (popular article)



And who did it? We automate information security audit



All Articles