Get best of the week

Windows vs Sysmon


At the last ZeroNights conference, in the course of informal communication with our colleagues in the monitoring system, we were asked a simple question at first glance - it was widely believed that Sysmon should be used to fully monitor the endpoint with Windows OS, is that so? And if so, for what specific reasons (hello Seryozha!)? We could not find an unambiguous comprehensive answer in our baggage of knowledge or a corresponding comparison on the Internet, therefore, first of all, for ourselves, and not least, so that in the future such a source would still be available from the community, we decided to explore this topic and compare Windows and Sysmon face-to-face events. As the saying goes, “1 ... 2 ... 3 ... Fight!”.


Introduction


Any specialist in the field of information security is forced to work within a certain framework. For example, within a limited budget, security, with rare exceptions, is not the main way for an organization to make a profit or perform other functions within its core business. Therefore, in conditions of limited resources that the organization possesses, only a small part of them is often allocated to the security sector in order to maintain this direction at the minimum sufficient level (in accordance with certain requirements). Even with unlimited resources, there will always be other restrictions that do not allow to bring the level of security to the absolute. These are the notorious vulnerabilities of zero or normal day (endless patch management), and the constant arms race of hackers and security guards,and the dynamism of the development of IT infrastructure, and much, much more.

In this light, more than ever, the issue of prioritizing protection means and methods is urgent, including in the direction of monitoring. In this area, according to statistics based on the data of the MITRE ATT & CK matrix , which we already wrote about last time, the priorities are as follows: unconditional first place is taken by such a source of security events as endpoints.


This source leads in the number of matrix techniques that can be identified based on events recorded on it. The most common OS for endpoints remains Microsoft Windows. Collecting exactly its logs in most corporate infrastructures will give the best result in the ratio of all types of costs to the coverage of network devices and the coverage of malicious techniques. This is confirmed by the statistics of the same authors. Places 1-3, 5, 7, 8, 10 and part 4 occupy just these so-called basic events.


But, as in the famous joke, there is one caveat. In recent years, it has become widely accepted that Windows logs need to be supplemented, if not replaced, with Sysmon events - they say they are more complete, better, more adapted as a monitoring tool from the point of view of information security.

In addition, this approach in some way meets the concept of minimalism. Each software product that you are trying to add to your own or voluntarily given to you by an enterprise customer is an increase in the attack area, administration and updating costs, and points of failure. And often - and just the time before the implementation of your monitoring system, while your approach passes approval.

Sysmon was developed by Microsoft specialists, and recently absorbed by this corporation, which gives a certain level of trust on the part of IT. In addition, the logs are written in the form of an .evtx log, which allows you to collect and process them using the same tools and methods as regular Windows logs.

Immediately make a reservation that the article turned out to be large, although we tried to duplicate and compress the material minimally. The reader, of course, can say, referring us to that joke about Lenin: “But he could have slashed ...”. Or that "the publication could be divided into two or three parts for greater readability." But it seemed to us that in spite of the volume of the prepared material, we must provide a complete answer to the question of our colleagues in the shop, and the search would be more convenient. Thus, in order not to lose anything, we recommend that you read the article 1 time completely, perhaps make notes for yourself and only then return to specific groups of events and delve into them in detail.

For convenience, we add a table of contents:
Introduction
Table of contents
Comparison format
Creating a process
Network connections
Ending a process
Downloading a driver
Access to a process
Creating a file
Registry actions
WMI configuration
DNS queries
Unique Sysmon
events Filtering events
Other free base event providers
General output

Comparison format


Why and what was compared, it seems to be clear. And how was this done and why exactly?

We decided to make a comparison in the form of a table for each of the groups of events that reflect a certain activity in the system. For example, events with ID (Event ID, EID) 12, 13 and 14 in Sysmon, reflecting activity with the registry, are not even filtered separately, although they speak of different atomic actions. By the same logic, the rest of the grouping was made.

Such groups included only similar events. For example, an analogue of the Sysmon EID 6 event is the Windows EID 6 event. At the same time, there are at least 219 and 7036 Windows events about loading drivers. But they arise in case of failure. Those. do not carry the same semantic load and, if necessary, can complement the events of Sysmon or Windows, depending on what we decided to collect.

For groups of events reflected in the table, informative (which we use for monitoring purposes) fields contained in events are presented in the form of strings. For each such field, its name is indicated. For Windows, 2 options are possible, for xml and magazine views (who would have thought that they would match?) If they differ more than by spaces. This is done because the name of the field that will fall into the monitoring system may depend on the collection method. The lines also contain event data (in order to understand their format) and a comment (if in our opinion this is required).

The fields with the same semantic load for both sources are combined in one line. In the absence of a field with a similar semantic load for one of the sources, dashes ("-") are indicated in the fields corresponding to it.

Lines containing information about a particular entity, for example, the subject performing the action, are combined into one semantic group.

The comparison was made for versions of Windows Kernel 6.3 (Windows 2012R2) and 10.0 (Windows 10, 2016, 2019). Earlier versions were not considered, since although they are still widespread, they are gradually disappearing. If the events for different kernel versions did not differ, the columns were combined into one to reduce duplication.

Since the rate is full-time, the columns are arranged in the following order from the center to the edges: data, field name, comment. This makes the comparison more visual. For visual separation of columns according to the sources to which they refer, colors are used.

Unique to Sysmon EID (since in this case it is a complementary tool, recording OS logs is included in the basic functionality of the OS) are given in a separate section.

The section with the table shows the GPO settings that must be made to enable recording in the group event log, as the number of possible audit options is generally quite large. For Sysmon, such settings are not shown, because all of them are contained in a single configuration file.

Process creation


Paradoxically, they decided to start from the beginning. And then they were also not original and went in order - in increasing EID Sysmon.

Logging of event data in Windows is enabled as follows:

• Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Detailed Tracking - Audit Process Creation - Success enables logging of the event itself;

• Computer Configuration - Policies - Administrative Templates - System - Audit Process Creation - Include command line in process creation events - adds the command line of the started process to the event, which often makes it possible to distinguish a legitimate start from an illegitimate one.

Comparison in the format described above is presented in the following table.


Hereinafter, all tables are represented by pictures and are clickable. Since, firstly, we did not find a good way to transfer tables to Markdown or HTML while preserving the column width or hyphenation according to the existing version in Excel. And secondly, their contents are not very valuable for indexing, except for comments. Much more valuable in tables is the composition of the fields discussed in this article and the data format that you will have to work with if these event sources are used.

Consider it in order, but not line by line - each will do such a detailed analysis for himself. In this section and below, we will dwell only on the information encountered for the first time. Immediately start with an example of this behavior. The fields of the System section are present in every event that falls into the log, regardless of the source - Sysmon or Windows. They include general information:

  • The name of the event provider.
  • EID
  • The time when the event was logged.
  • The name of the magazine where we got this event from.
  • The host on which the event occurred.

The name of the provider and log after connection are usually not used by the analyst. But they make it possible to understand where and who writes the logs, which is important if the collection process has not yet begun. Time, host and EID are the main beacons by which the primary filtering of events is performed.

Further, among the fields that I would particularly like to note - the GUID for both the user session and the child and parent processes exists only in the Sysmon logs. And to the same piggy bank, out of oddities - the process ID (new and parent) in Windows events is written in hexadecimal, although it is displayed in decimal notation in the same Task Manager. As the saying goes, happy debugging ("-Want to improve? -Github") ...

The command line when starting a process in Windows events has a different format depending on the utility used to start it. But in Sysmon, the authors wanted and could - the format does not depend on other input. I’m not going to judge the reasons, but the creators of SIEM content will not write thanks to Microsoft about this, that’s for sure.

The main distinguishing feature of Sysmon for this, as well as for other events that contain this field, I would call the hash of the executable file. The hash format is selected in the Sysmon configuration.

Again, from the additional interesting Sysmon bonuses - the Rule Name field. This is, in fact, a tag that is convenient to mark certain filters in the config file, and then use it when analyzing events. For example, we can say that the start of process X refers to tactics Y or technique Z. This approach is interesting both from the point of view of the analyst and from the point of view of the content developer SIEM or Sysmon - it allows us to understand the reason why we decided to collect this event.

Conclusion


Sysmon is much better for fixing this group of events:

  • GUID , , , , ID ( ). , , . . ID , , SIEM, . GUID, — .
  • — — , , . — Sysmon , SIEM ( ). - — , . , SIEM . , , IBM QRadar. , - . , , — Windows , , .
  • Rule Name .
  • The applicability of the remaining unique fields, that in Windows events, that in Sysmon events, plays a role, as they say in English, case by case. Therefore, to decide on the choice of a particular log, or in general combining them, also need case by case.

Network connections


Recording these events on Windows: Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Audit Filtering Platform Connection

Why did you decide to focus on the events of the Windows Filtering Platform (WFP), and not the Windows Firewall? The answer is simple. Based on our practice, the endpoints in the form of antiviruses are already on the hosts anyway. Although they are not designed to monitor the basic events of the system (which is why they are not suitable for our purposes), nevertheless, in modern realities, they always include a host firewall. For this reason, to avoid duplication, Windows Firewall is usually simply canceled. Accordingly, no one writes to the colonel ... WFP, however, although it can filter traffic, we use it only for monitoring. Therefore, duplication is absent.


The table shows that if we try to rely on Windows events, then the user ultrasound and the FQDN of the interacting hosts will have to be restored by event enrichment. Although, if you think about it, it’s more important for us to know which process has established the connection, and not which user. For example, the malware goes to its C&C center. Anyway, we want to find out who started the process or create an incident based on the understanding that notepad does not go to the Internet itself (i.e. based on the information available in the event).

And with FQDN it’s even simpler - all modern systems include the CMDB component as a basic or additional functionality. And if not, it’s definitely worth stocking up with a third-party solution. Knowing your infrastructure is the basis of information security in general. So the information is available either through enrichment or through an asset card, which will allow its use in correlation. The main thing is, if possible, not to forget to connect DHCP logs so that the information is up to date.

All other unique fields are not so significant, for example:

  • Famous ports. We would not rely on this field - it is not in vain that there are means to detect anomalies in traffic when, for example, the ssh tunnel goes through port 80 rather than HTTP.
  • Traffic direction. Knowing the host ID (IP or FQDN) and the source \ destination of the connection, you can easily calculate the direction.

Conclusion


And in this case, Sysmon wins, but less significantly - GUID, FQDN, User provide a convenience that is quite possible to achieve using SIEM or third-party solutions. Nevertheless, small efforts do not mean zero.

Process completion


In general, the event, as already mentioned above, is not very often used, but ...


If it is needed, then there is a clear win on the side of Windows. We add only how to enable logging, and go straight to the conclusions.

Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Detailed Tracking - Audit Process Termination - Success

Conclusion


In this case, the advantage of native OS logging is achieved by:

  • Displays the user who completed the process.
  • The presence of Exit Code, which can talk about the regular completion of the process, as well as errors.

Driver download


This Windows event, unlike the others, is enabled by default and gets into the System log. There are not many informative fields in these events.


And again, immediately to the conclusions.

Conclusion


In this group, Sysmon events provide the analyst with much more useful information. For example, according to Windows events, it is not even clear which driver file was used. Therefore, in this group of Windows in explicit outsiders.

Process access


We would not classify this group of events as basic, but rather a slightly advanced level. From a security point of view, the event can be of great interest. There are many ways a malicious process can make your legitimate little “better.” Of course, not for the sake of altruism, but for malicious actions. And the events under consideration will just help us discover many options for such creativity. These logs are enabled in Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Audit Kernel Object - Success


Windows has two advantages. Firstly, the mapping of the user from whom the source process is working. As we noted above, the advantage is usually negligible. And, secondly, HandleID and access rights.

If the interest in access rights is clear, then HandleID is useful only for searching related events. It is necessary for organizing user interaction through processes with OS objects - the same processes (their threads), files, etc. Accordingly, additional events can show how, as a result, and to whom it was issued and when the required handle for access was revoked.

Touching on the topic of objects and handle for the first time, as well as logging actions with them, it is important to note two things.

First, to log the above additional steps, it is important to enable additional audit policy settings, in particular Computer Configuration - Polcies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Audit Handle Manipulation - Success. It is worth remembering that the volume of these events can be very large. Handle is issued upon receipt of a request, respectively, reflects the claimed rights. But why can we not expect the same volume of events directly from the audit of access to objects?

This is because, secondly, it is necessary to enable SACL on the object that is planned to be controlled. In fact, this is a list similar to the list of DACL access rights, which determines whether the subject or object created with its token will receive success or failure when trying to access the object. But the SACL determines in approximately the same form not the rights to interact with the object, but whether security events will be generated when requesting and exercising certain rights. These events will include not already requested, but actually used access rights.

As a result, we get a filter that allows you to log only access to objects that are critical for us and only those types of access that are important to us. But in return, we must attach a SACL directly to each such object or indicate that the SACL is inherited from the parent object. Of course, this can be automated by various methods. But maintaining the configuration of such automation tools is unlikely to be convenient. Unlike a simple Sysmon list, which can also include wildcards, albeit peculiar ones. We will talk about filtering in Sysmon in a separate section.

Fortunately, for objects of type, a SACL process already exists by default for the kernel version 6.3 and higher. If someone can specify a way how to receive this SACL (recommendations from this articlewe failed to fulfill), it will be interesting to hear / discuss.

On the Sysmon side, in addition to the GUIDs and Rule Names already discussed, there are several more interesting fields. First, the PID of the target process. It will allow you to monitor the subsequent activity of the infected object, because there can be several instances from one executable file. Secondly, the CallTrace field, which captures the actions of the event source in the target. Look at this and realize that “sleight of hand and no fraud” are not just words. On the other hand, such a detailed analysis is already the fate of forensics. And whoever has a dedicated forensic is most likely not at the beginning of the path to building a monitoring system.

Conclusion


In this group, events differ in a fairly large number of fields. But if in Windows events this information most likely provides the convenience of initial analysis, then Sysmon captures unique data that is difficult to obtain in any other way. Therefore, the advantage remains with Sysmon.

File creation


This category is included in Windows as follows: Computer Configuration - Polcies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Audit File System - Success


As can be seen from the table, all the pros and cons of this group are similar to those already described above. Including the pros and cons of SACL (for files and folders for all (Everyone) users, includes Properties - Security - Advanced - Auditing - Add - Everyone - Success - Write (for files) or Modify (for a directory)).

You can also set SACL on files globally by defining it in Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Global Object Access Auditing - File System. But the number of events, especially with temporary files, will increase in proportion to the volume of operations. I would not say that this is an effective approach, it is possible only for a small part of operations.

I would like to note the logging oddities that begin here. For this group is not fixed Windows event when a file is created through Powershell, for example, the New-Item the C: \ FORTEST \ test.t . At the same time, the same action is displayed perfectly in the Sysmon logs.

Conclusion


This event group is best recorded using Sysmon.

Registry Actions


So far, speaking of the group, we have included only one event in it. This trend will change here.


Logging of these events is configured as follows: Computer Configuration - Polcies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Audit Registry - Success.

SACL for all (Everyone) users is defined as follows: regedit.exe - registry branch - Permissions - Advanced - Auditing - Everyone - Success - Advanced Permissions - Full Control or Set Value, Create Subkey, Create Link, Delete, Write DAC.

You can also set SACL on files globally by defining it in Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Object Access - Global Object Access Auditing - Registry. Cons of the approach are similar to the same file operations.

Immediately focus on the limitations. For Sysmon, all operations (create, modify, delete) with value or key raise events (except for renaming value). For Windows:

  • All operations with value raise events.
  • Creating a key does not raise events.
  • Renaming key raises only the Access event; the new key name is not displayed; the requested rights specified in the event do not have an intuitively unambiguous correspondence with the operation. Thus, the renaming operation can only be determined by the exception method - there is no delete event 4660 with this HandleID.
  • Removing key raises event 4663 followed by 4660.

In addition to the fields discussed in the previous sections, it is important to note that Windows events contain old and new data of names and values ​​of key and value, which during the investigation can help to understand the motive of the attacker. Especially if the initial values ​​are not standard or typical, and the configuration, including the registry data of the machine under investigation, is not stored anywhere outside the host.

Conclusion


As we can see, there are more stringent restrictions on Windows logging. And to fix some facts, a “correlation” is needed at all, albeit the simplest. However, it is able to provide a larger amount of really useful information. It is difficult to give preference to one of the participants for this group of events.

WMI configuration


We pass to the penultimate group of events. These are WMI events. An attacker can create a filter (filter) that receives any events about a change in the state of the system, in our example, a change in the state of a service. And to carry out certain actions based on the events received from this filter, creating a consumer. In our case, this is an entry in the log file. Next, he must connect the filter output to the consumer input, creating a binding between the filter and the consumer. It will turn out a system that works under given conditions. Often used for Persistence tactics . It is precisely in the described order that events 19-21 Sysmon are recorded.

It is important to understand that creating a filter or consumer in itself does not pose a threat, but, of course, can be part of an attack. Moreover, for malicious activity, an existing filter, a consumer, or both can be used. Here it’s like with a knife, or, closer to the topic of the resource, with encrypted messengers. The question is not in the tool, but in its use.

Let’s take a closer look at the table.


An important point that should be noted first of all - event 5861 is generated in the specified log only on the fact of the creation or subsequent modification (including in terms of filter and consumer) of the bundle. This, on the one hand, makes it easier to track allegedly malicious activity (no correlation between two or three events is needed) if not only a bunch is created within it. And on the other hand, we miss the start time of this activity if the filter or consumer is created precisely within the framework of it and ahead of time.

Is this critical? Case by case. If we begin to unwind the sequence of an incident and see that an atypical and supposedly malicious filter or consumer was created two years ago, then we immediately realize that the attackers have been at home with us for more than two years. And traces of the attack must be sought at least to this depth. How often does this happen? This is the main question.

But if changes are made to the filter or the consumer of the existing bundle, we will see the whole picture in a single event. While Sysmon will reflect only those changes (that object) which were made.

Among other differences: in Sysmon events, data is reflected in a more structured form and in a more convenient format. For example, instead of the SID in an atypical format, the user's login is immediately presented. But the data is a little less. Perhaps this is critical for your case.

We conclude with restrictions. Firstly, despite the fact that this journal has been present since Windows 2012 (kernel 6.2), we were not able to get these events even for kernel 6.3 (2012R2), which is studied in the article. Perhaps this is due to the absence of any patches.

Secondly, according to the author of thisarticles, the filter for timer events is not fixed by Sysmon. It would be possible not to take a word, but to check. Moreover, the version of Sysmon is old. But here a precedent is important - there are not a few types of filters and WMI consumers. From such a study, supplemented by details, a separate article could be made. Just test the target types to understand exactly what they will be registered.

Conclusion


In this case, we are more comfortable with using Windows events. As from the point of view of convenience: more data, there is no need for primary correlation. So from the point of view of goal-setting - it fixes the creation of a mechanism (based on new, modified or existing parts), and not its individual pieces.

DNS queries


So, we move on to the final group being compared, but still far from the conclusion of our article. This type and the corresponding set of events are recent not only by the appearance in our article, but also by adding Sysmon to the toolkit.

Over the past few years, the topic of using DNS for other purposes, for example, to receive commands from C&C or steal information through this channel, has become popular. Most likely not by itself - we would refer the stories about such use of ICMP and DNS channels to zero. At that time, familiar students were sophisticated in the encapsulation of toy traffic in order to reach the coveted game servers from the institute’s network via the only allowed channels (hello, Zhenyatumbochko!). This made it possible to somehow pass the time on boring or quickly mastered their labs. And it was hardly their idea.

But not so long ago, a concept such as DoH was added to this leak channel, which complicated the detection of suspicious DNS traffic at the network level.

Or perhaps it was just a marketing ploy - to sell a new one, which is also a well-forgotten old one. Or the onset of the widespread occurrence of such channels in detectable malicious activity. We did not dig deep into this issue, prepared to collect grains - suddenly one of the readers decides to drop a little wisdom in the comments.

So, closer to the point. Turn on Event Viewer - Application and Services Logs - Microsoft - Windows - DNS Client Events - Operational - Context menu - Enable Log.


All the same as already discussed. As for the information about the subject, we pay attention to the explicit indication of the image of the executable file that executed the request in the Sysmon event.

If we talk about the object - there is much more information in the Windows logs. But there are several important “buts.” Firstly, the information is distributed over several events with all the consequences.

Secondly, the information is presented in an unintuitive way. Decryption of the majority requires knowledge of how the fields of the package are formed, and the ability to transform this data back into facts that contribute to the analyst making a decision. We can say that, in fact, the analyst is not in vain getting a salary and why not sit down and figure it out. Yes, that's right. But I remind you, we are talking about a small team without narrow-profile specialists, before which there is no end to the tasks in information security. And if for every event analyzed by SIEM, such a task falls on him, he will not catch up with them in a few years.

Conclusion


For this group, the winner is difficult to determine. Sysmon offers a laconic version, from which you can easily squeeze a good portion of useful information. Windows offers an advanced option. It remains to “sew” it, deal with the content and ask yourself if it was time to introduce NTA?

Unique Sysmon Events


We attributed the following to Sysmon's unique events:

  • EID 4, 16. Although it can be tracked through Windows logs, they only tell us about the events in Sysmon itself. Accordingly, in its absence they do not make sense.
  • EID 2 - EID 4663 could be considered as an analogue. But even taking into account the access rights lists provided in it, the event is not as granular as EID2, and it is not enriched to such a state with other Windows events.
  • EID 7-9, 17 — . ETW. , , .
  • EID 15 — , ETW. , — .
  • EID 18 — (named pipes) . , -, . -, , . ETW.


There are three options for filtering events on the source side.

The first is available only for Windows events and only for monitoring access and operations with objects. Implemented using SACL. Among the disadvantages of this approach is the complexity of the granular settings (for example, you cannot only monitor existing or created files with the .exe extension). Among the advantages is the ability to limit the list of users for whom operations with the object are recorded.

The second is available for both Windows events and Sysmon events: using Xpath, taking into account the restrictions imposed by the great Microsoft. Since the method is available for both sources, the description is beyond the scope of this article.

And the third is the Sysmon config. There are many options:

  • Wildcard emulation - contains (any | all), excludes (any | all), end with, begin with. Using contains | exludes all allows you to emulate expressions like "C: \ Windows \ *. Exe".
  • Exact match - is, is not, image.
  • Arithmetic - less than, more than.

It should be noted that such filtering is not available for all fields. For example, you cannot whitelist hashes of standard software, the creation of processes for which we are not interested. An example from our experience - the legitimate process git.exe created tens of thousands of start events per day on the hosts of our developers. Perhaps, specifically in this case, his behavior could be tightened, thereby reducing this shaft of events. But excluding executable files by image name is not a good idea. Well, maybe only an antivirus with self-defense enabled.

Sysmon is also only on its way to sophisticated filtering by combining conditions from different fields. You can create only one group of rules for each EID combined by AND relationships, and only one with OR relationships. Accordingly, conditions of the form (A and B) or (C and D) can no longer be written. Depending on the filtered stream, this fact may not give any significant advantage, but also give a tangible result.

Other free base event providers


In this section, first of all, I would like to talk about the ETW (Event Trace for Windows) mechanism . Both the Windows and Sysmon built-in logs log events using this mechanism. In fact, for every action in the system we can get an event. The easiest way to look at the potential volume of such events is by enabling the Event Viewer - View - Show Analytics and Debug log option. So that events do not immediately fill your system, each log is activated separately in its context menu. You look at this goodness and involuntarily ask yourself a question - why do we need Sysmon with such a volume of various events?

The fact is that, firstly, these logs were originally intended for debugging, and not for security purposes. Therefore, their centralized collection is not provided. In particular, you will not find the FQDN of the host on which they were created anywhere. The question, of course, can be resolved by third-party utilities from small to large, from scripts to full-fledged logging services. But you need to remember that this is additional software in a large enterprise, and, accordingly, a separate task. Let me remind you that in the introduction we proceeded from the principle of minimalism in additional activity for installing software.

And secondly, these logs report in so much detail about each sneeze that they also have to select the information bit by bit. Journal entries are truly atomic and will require prior correlation or enrichment for the analyst to work productively. After all, a programmer who debugs his creation using these events knows how everything should work. And a security guard, especially of a wide profile, thinks at much higher levels of abstraction. Yes, in addition, it searches for unknown illegitimate activity. Such a statement of the problem leads to an additional software module that will carry out pre-processing. This will again complicate our concept.

While we have not gone far from logging using Windows, we will not forget to mention WMI. This tool basically captures state changes without displaying their source. As an example of an exception, loading a dll: displays the dll module itself and the process that is loading it. But for security purposes, this event also requires enrichment, as this is where its information is exhausted. In general, fishlessness and cancer are fish. But the tool can only be used as an extra.

Another popular option, but not covered in the article, is osquery.. The two main reasons why we did not consider this solution here are the low frequency of product updates (minus both in terms of security and functionality) and increased use of system resources compared to other options (a full database is included). Presumably, the solution is well suited for servers for which it was developed. But for workstations, possibly with outdated hardware - hardly.

Recently, several more tools have appeared that are not as widespread as those considered. These include Velociraptor and SilkETW. They do not invent a bicycle and also work on top of the Windows standard - ETW. In view of the volume of material already cited, it was decided to separate these tools into a separate publication (as time and effort are available, as well as a sense of demand).

General conclusion


In the course of the comparison, it was shown that Sysmon events that have analogues usually outperform Windows events in their functional characteristics. Some Sysmon events simply have no alternatives.

However, do not forget that, firstly, the solution must be chosen based on your tasks. If you are just building a monitoring system and in the first year you plan to implement methods for detecting seven to ten incidents, as Gartner bequeathed, then you should have enough Windows events. And perhaps much more than a year.

Secondly, the Windows event logging system is also constantly updated, and during the writing of this article, Windows EIDs such as 4798 and 4799 appeared. It is also possible that the set of fields is supplemented. Thus, this comparison, although it is the most complete, based on the information that we possess, is not carved in stone.

And thirdly, Sysmon is still an external tool, which entails a number of risks. For example, we have had cases when the logging of individual EIDs was terminated without declaring a reason. In this case, the recording of other events was as usual. More eminent colleagues claim that the problem was related to memory leaks in version 10.41. But release 10.42, in which this problem is closed in whole or in part (with Sysmon's changelog, everything is not so detailed), did not solve our problems in this direction. Only uninstall-install component helps. All security and have a nice day!

Thanks to Timurzinintfor help in preparing the publication.

UPD1 : It turns out to be really difficult to maintain a normal change log or add new features to the main description, so as we discovered (thanks, Uncle Dimshudv), a truck with nishtyaks turned over on our street already 9 months ago ... Summary: in Sysmon you can do (A and B) or (C and D), only shh ...

More articles:


All Articles