Sysmon can now write clipboard contents
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. It could be system (0)
when working online 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 in which the copied text was saved (similar to working with events of the FileDelete type).
Archived: status, whether the 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 appropriate settings) save different 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.
Saving to file is enabled during installation. You can set up whitelisting processes for which the text will not be saved.
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. Assuming 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;
- Capturing 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 fact of access to the archive directory and identify potentially dangerous (not initiated by sysmon.exe).
You can use the tool to record, analyze and react to the events listed above. InTrust, 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 costs of their licensing by transferring processing and storing 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 enable the collection of events about the launch of suspicious processes in Windows and identify threats using Quest InTrust
How InTrust Can Help Reduce RDP Login Failures
Identifying a ransomware attack, gaining access to a domain controller and trying to resist these attacks
What is useful to extract from the logs of a Windows workstation (popular article)
Who did it? We automate information security audit
