Correlating event ID 4658 with 4656, and SysMon id:1 with SysMon id:5.

[InfoSec]

Anyone with any idea about how to correlate the handle ID between Windows event IDs 4656 & 4658.

We want to collect event 4658 only if the Handle ID in event ID 4658 has appeared previously in a collected 4656 event, otherwise drop.

A similar scenario presents itself with SysMon event ID 1 & event ID 5.

We want to collect Sysmon event ID 5 only it was preceded by a Sysmon Event ID 1 with the same Process GUID, otherwise drop.

Both Handle ID and Process GUID are values that are randomly assigned by the system respectively when a new handle is opened, and when a new process is created. Both should be reasonably unique for a session.

Microsoft has made our life difficult by not including sufficient information in the "close" event, unless correlated with the corresponding "open" event.

The correlation link between the two is the Handle ID for 4656 & 4658, and Process Guid for sysmon event ID 1 and ID 5.

[Chema Martinez]

Hi InfoSec,

I am afraid that for now, the Wazuh ruleset is not able to correlate fields between two alerts triggered in a different time.

The closest solution for that purpose would be using the option <if_matched_sid> which allows you to trigger an alert only if the rule ID specified in that field was triggered before. However, there is not an option to keep fields from previous alerts and matching them with the new ones. Sorry for the inconvenience.

Anyway, why do you need to monitor both events (open and close) instead of monitoring only the last one?

Best regards,

Chema Martinez | IT Engineer — Wazuh, Inc.

--
You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/f654ed52-64a0-4ea7-93be-60028e5b1810%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Georges Jahchan]

Here's what event 4658 (sanitized) contains:

- 

<EventData>
    <Data Name="SubjectUserSid">S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx</Data>
    <Data Name="SubjectUserName">Santized</Data>
    <Data Name="SubjectDomainName">Santized</Data>
    <Data Name="SubjectLogonId">0x697e37</Data>
    <Data Name="ObjectServer">Security</Data>
    <Data Name="HandleId">0x2e24</Data>
    <Data Name="ProcessId">0x3a2c</Data>
    <Data Name="ProcessName">C:\Windows\explorer.</Data>
</EventData>

- And Event 4656 (sanitized) pointing to the same HandleId:

<EventData>
  <Data Name="SubjectUserSid">S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx</Data>
  <Data Name="SubjectUserName">Sanitized</Data>
  <Data Name="SubjectDomainName">Sanitized</Data>
  <Data Name="SubjectLogonId">0x697e37</Data>
  <Data Name="ObjectServer">Security</Data>
  <Data Name="ObjectType">File</Data>
  <Data Name="ObjectName">Sanitized</Data>
  <Data Name="HandleId">0x2e24</Data>
  <Data Name="AccessList">%%4416</Data>
  <Data Name="AccessMask">0x1</Data>
  <Data Name="ProcessId">0x3a2c</Data>
  <Data Name="ProcessName">C:\Windows\explorer.exe</Data>
  <Data Name="ResourceAttributes"/>
</EventData>

As is evident in the samples above, unless we are able to correlate the HandleId with the same HandleId in Event 4656, we are clueless as to the ObjectName, ObjectType, and ObjectServer of the 4658 event.

Unless we are able to filter event 4658 in such a way that it is dropped if there was not an event 4656 with the same HandleId preceding it, collecting 4658's with no filtering criteria is enormously noisy.

[Chema Martinez]

Hi Georges,

Sorry for the late response.

I understand that would be very interesting for you to have the ability to correlate both events but unfortunately, it is a limitation for Wazuh today.

I think that maybe you could use the visualizations and filters available in Kibana to reach an approach by making easier the comparison between alerts generated by events 4656 and 4658. Nevertheless, alerts will continue being triggered on the manager.

Sorry for the inconvenience.

Best regards,

Chema. 

Chema Martinez | IT Engineer — Wazuh, Inc.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/0ff9a4be-e29e-4ef0-86c1-ac8bfd464511%40googlegroups.com.

[InfoSec]

To be effective/efficient, the "keep or drop" decision needs to take place on the agent before collection, and not on the server. If performed on the server, it is already "too late". The endpoint would have been kept very busy forwarding tons of 4658 events that are overwhelmingly useless noise.

Windows generates an incredible volume of 4658 (handle closed) events, which unlike the 4656 (handle open) do not include the object name, only the handle ID.

On the agent, the cycle would be as follows:

- Push the handle ID of 4656 events forwarded to the server into a local dynamic handle ID lookup list (which could be maintained in memory, not on disk).

- For 4658 events, check for the presence of the handle ID in the handle ID lookup list:
  - If present, collect the 4658 event, and delete the handle ID from the list.

  - If handle ID is not present in the handle ID lookup list, drop the event.

The handle ID is randomly generated on the endpoint. Should the keep/drop decision be made on the server, the list must then include both the Handle ID and the Agent ID or name, as randomness is per endpoint, and not across endpoints.

I know the capability is currently not there, neither on the agent nor on the server.

Question is two-fold:

1.- Is it technically feasible/doable on the Windows agent side?

2.- If the answer to 1 is yes, will Wazuh look into adding it as a feature sometime in the future?

[Chema Martinez]

Hi InfoSec,

That would be a good approach for your use case, no doubt about that. In fact, on Linux agents there exists an integration with Auditd that collects events with a specific key grouping them internally by the log collector daemon and send them to the manager to get the Who Data information. For Windows agents, I see the inconvenience that you want correlate events from different timestamps, among others facts we would have to take into account when thinking about developing something like this:

- Agents philosophy is to be the most light as possible delegating the most load of computing on the manager side. This way, agents have the least possible impact on machines destinated to its own purpose.

- Also related to the previous point, the agents don`t have any logic to decode and process event fields, as well as making operations on them. Their architecture is focused on collect data forwarding it to the manager, so facing a change like this one means to change that flow of data and, consequently, its philosophy.

I understand your purpose and your necessities, and of course, we will think about it to try to find out a balanced solution for this use case.

Meanwhile, I think you could use an intermediate script to collect the Windows events in which you are interested. Storing them into an SQLite database where to do the correlation process and after that, send the result data directly to the agent daemon queue.

Hope it helps.

Best regards,

Chema.

Chema Martinez | IT Engineer — Wazuh, Inc.

--

You received this message because you are subscribed to the Google Groups "Wazuh mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+unsubscribe@googlegroups.com.
To post to this group, send email to wa...@googlegroups.com.
Visit this group at https://groups.google.com/group/wazuh.

To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/dc7a69f9-44bc-4941-9c8d-25a7c44a62ec%40googlegroups.com.