The release of version 12 of Sysmon was announced on September 17 at . In fact, new versions of Process Monitor and ProcDump were also released on that day. In this article, I will talk about the key and controversial innovation of Sysmon version 12 - an event type with Event ID 24, into which work with the clipboard is logged.
Information from this type of event opens up new ways to control suspicious activity (as well as new vulnerabilities). So, you can understand who, from where and what exactly they tried to copy. Under the cut, 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 whose data was written to the clipboard.
session: the session that wrote to the clipboard. It could be system(0)
when working in interactive or remote mode, 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 to the Sysmon archive directory.
The last couple of fields are alarming. The fact is that since 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 as a result of 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
Saving to a file is enabled during installation. You can set whitelists of processes for which the text will not be saved.
This is what a Sysmon installation looks like with the appropriate archive directory setup:
Here, I think it's worth remembering password managers that also use the clipboard. Having Sysmon on a system with a password manager will 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 the password manager process, but maybe some svchost), this exception can be added to the white list and not saved.
Maybe you did not know, but the text from the clipboard is captured by the remote server when you switch to it in RDP session mode. If you have something on your clipboard and switch between RDP sessions, that information will travel with you.
Let's summarize Sysmon's clipboard capabilities.
Fixed:
- Text copy of 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 the text has not yet been pasted.
Not fixed:
- Copy/paste files from/to local virtual machine;
- Copy/paste files via RDP
- A malware that hijacks your clipboard only writes to the clipboard itself.
For all its ambiguity, this type of event will allow you to restore the algorithm of the attacker's actions and help identify previously inaccessible data for the formation of postmortems after attacks. If writing content to the clipboard is still enabled, it is important to record every access to the archive directory and identify potentially dangerous ones (not initiated by sysmon.exe).
To capture, analyze and react to the events listed above, you can use the tool , which combines all three approaches and, in addition, 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 the processing and storage of raw data to InTrust.
To learn more about InTrust, read our previous articles or .
(popular article)
Source: habr.com
