Monitor "Forwarded Events" channel

[Jérémy]

Hello,

Is it possible to monitor "Forwarded Events" channel on Windows systems?

I don't feel like it when I look at the documentation:

https://documentation.wazuh.com/3.x/user-manual/capabilities/log-data-collection/how-to-collect-wlogs.html#filtering-events-from-windows-event-channel-with-queries

Regards,

[Cristina Garrido López]

Hi Jérémy,

Yes, you can monitor this channel by configuring a localfile block with the location field set to 'forwardedevents', as below:

  <localfile>
    <location>forwardedevents</location>
    <log_format>eventchannel</log_format>
  </localfile>

Kind regards,

Cristina

[Jérémy]

Hi Cristina,

thanks for your rapid answer! It's seem to be woks.

I have an another question :

How I can test an event of the event viewer with ossec-logtest?

Regards,

[Cristina Garrido López]

Hi Jérémy,

These events can be tested in a different way, as they are passed to an internal decoder which is not contemplated at ossec-logtest. You can achieve this by making some changes to the EventChannel parent rule. The rule is located at the 0575-win-base_rules.xml file and has the ID 60000. Make the following changes to it:

- Remove the <category>ossec</category> option.

- Change the <decoded_as>windows_eventchannel</decoded_as> option by <decoded_as>json</decoded_as>.

Then, enable the <logall> option from the ossec.conf file in order to receive the events at the /var/ossec/logs/archives/archives.log file. In this file you can find the generated events in JSON format, then you will pass them to ossec-logtest in order to test them. Don't forget to revert the changes for rule 60000 when you have finished testing. Let me know if you have any more doubts.

Kind regards,

Cristina

[Jérémy]

Thank you, I'll test it in the next few days. 

I have one last question :

I wrote a rule file for our Fortigate firewalls :

<group name="fortigate,syslog,">

<rule id="100100" level="0">

        <decoded_as>fortigate-firewall-v5</decoded_as>

        <description>XXX firewall messages grouped.</description>

    </rule>

<rule id="100101" level="0">

<if_sid>100100</if_sid>

        <match>subtype=ips</match>

        <description>XXX IPS messages grouped.</description>

    </rule>

<!-- Ignore XXX -->

<rule id="100102" level="0">

        <if_sid>100101</if_sid>

        <match>srcip=X.X.X.X|srcip=X.X.X.X</match>

        <description>XXX IPS XXX messages grouped.</description>

    </rule>

<!-- Ignore XXX -->

<rule id="100103" level="0">

        <if_sid>100101</if_sid>

        <srcip>!X.X.X.X/19</srcip>

        <dstip>!X.X.X.X/19</dstip>

        <description>X.X.X.X IPS XXX messages grouped.</description>

    </rule>

<!-- Rules for firewall back. ID: 100110 to 100140 -->

<rule id="100111" level="0">

<if_sid>100101</if_sid>

<match>devname=XXX|devname=XXX</match>

        <description>XXX firewall back messages grouped.</description>

    </rule>

<rule id="100112" level="3">

<if_sid>100111</if_sid>

        <match>severity=information</match>

        <description>XXX IPS back information messages.</description>

    </rule>

<rule id="100113" level="5">

        <if_sid>100111</if_sid>

        <match>severity=low</match>

        <description>XXX IPS back low messages.</description>

    </rule>

<rule id="100114" level="8">

        <if_sid>100111</if_sid>

        <match>severity=medium</match>

        <description>XXX IPS back  medium messages.</description>

    </rule>

<rule id="100115" level="11">

        <if_sid>100111</if_sid>

        <match>severity=high</match>

        <description>XXX IPS back high messages.</description>

    </rule>

<rule id="100116" level="15">

        <if_sid>100111</if_sid>

        <match>severity=critical</match>

        <description>XXX IPS back critical messages.</description>

    </rule>

 .....

when I test with this log:

date=2019-05-22 time=15:39:44 devname=XXX devid=XXX logid=0419016384 type=utm subtype=ips eventtype=signature level=alert vd=XXX severity=high srcip=XXX srccountry="Reserved" dstip=XXX srcintf="XXX" dstintf="XXX" policyid=62 sessionid=1767584673 action=dropped proto=6 service="FTP" attack="SSH.Client.Key.Exchange.Overflow" srcport=21 dstport=51209 direction=incoming attackid=11908 profile="default" ref="http://www.fortinet.com/ids/VID11908" incidentserialno=1739496163 msg="applications: SSH.Client.Key.Exchange.Overflow," crscore=30 crlevel=high

it works correctly, and rule 100103 is matched.

However, if I set the level of rule 100103 to 3. It no longer works, the rule matched is 100115.

Can you explain this behaviour to me?

Regards,

[Jérémy]

I come back to you because I have a problem with the "Forwarded Event" channel:

2019/05/22 16:18:17 ossec-agent: ERROR: Could not EvtOpenPublisherMetadata() with flags (1) which returned (2)

2019/05/22 16:18:17 ossec-agent: ERROR: Could not get message for (forwardedevents)

2019/05/22 16:18:17 ossec-agent: ERROR: Could not EvtOpenPublisherMetadata() with flags (1) which returned (2)

2019/05/22 16:18:17 ossec-agent: ERROR: Could not get message for (forwardedevents)

Have you any ideas?

Regards,

[Jérémy]

Hi!

we managed to debug our problem with the Fortigate rules.

However, we still have the problem with Forwarded Events. I found this issue on github :

https://github.com/ossec/ossec-hids/issues/1385

Do you have more information?

Kind regards,

Le mercredi 22 mai 2019 16:31:28 UTC+2, Jérémy a écrit :

[Cristina Garrido López]

Hi Jérémy,

Regarding your first email about Fortigate rules, this is totally normal. Rules with level 0 have priority even though they are silenced, this is why your rule 100103 with level 0 is matching and not 100115. If you change this alert level to 3, logtest will search for the next rule with level 0 or higher than level 3. As your rule with ID 100115 matches with 100111, which has alert level 0, it triggers this alert. If you want to match rule 100103, you can change 100111's alert level to be 3, or change their order.

Regarding your problem with Forwarded Events, can you tell me the Windows version you are using? Also, the error code is 2, which means that it cannot find the file for this channel. Have you enabled the event forwarding in your system? Is your system registering any event at the channel Forwarded Events at the Event Viewer?

Kind regards,

Cristina

[Jérémy]

Yes, we deduced the same for Firewalls. :)

For the Forwarded Event problem, here is the information:

Windows version: Windows Server 2016 (OS Build 14393.2969)

The Event Forwarding channel is well activated, and there are events in it.

[Cristina Garrido López]

Hi Jérémy,

It seems that this error occurs when the event's provider name isn't known or doesn't exist. Could you tell me which is the provider name of some of the events included at your "Forwarded Events" channel at the Event Viewer?

Kind regards,

Cristina

[Jérémy]

Hi Cristina, 

We only have this log provider in the Forwarded Events:

- Microsoft Windows security auditing.

Regards,

[Jérémy]

In fact, we have no more errors this morning in the logs with this configuration : 

  <localfile>

<location>forwardedevents</location>

    <log_format>eventchannel</log_format>

  </localfile>

......

It's ok, however, to test the logs we receive, I don't see the file "575-win-base_rules.xml". We are in version 3.7.2 on the cluster.

Sincerely,

[Cristina Garrido López]

Hi Jérémy,

If you are using 3.7.2 it is not necessary to make the changes I mentioned for this file, as eventchannel has been enhanced for Wazuh 3.8 retrieving much more information in JSON format.

As you are using the old version of eventchannel, you don't need to modify this rule. It would be enough pasting the logs you want to test at ossec-logtest.

Let me know if the problem about the EvtOpenPublisherMetadata function keeps showing.

Kind regards,

Cristina

[Jérémy]

the Wazuh cluster is in version 3.7.2, the agent on the server where Forwarded Events are activated is in version 3.8.2.

when I activate logall on workers, I receive the events of the Forwarded Events channel :

archives.log:59902:2019 May 27 11:24:49 (XXX) any->EventChannel {"Message":"An account was successfully logged on.","Event":"<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-Security-Auditing' Guid='{XXX}'/><EventID>4624</EventID><Version>2</Version><Level>0</Level><Task>12544</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime='2019-05-27T09:24:39.607340700Z'/><EventRecordID>8900711</EventRecordID><Correlation/><Execution ProcessID='560' ThreadID='1980'/><Channel>Security</Channel><Computer>XXX</Computer><Security/></System><EventData><Data Name='SubjectUserSid'>S-1-0-0</Data><Data Name='SubjectUserName'>-</Data><Data Name='SubjectDomainName'>-</Data><Data Name='SubjectLogonId'>0x0</Data><Data Name='TargetUserSid'>XXX</Data><Data Name='TargetUserName'>XXX$</Data><Data Name='TargetDomainName'>XXX</Data><Data Name='TargetLogonId'>XXX</Data><Data Name='LogonType'>3</Data><Data Name='LogonProcessName'>Kerberos</Data><Data Name='AuthenticationPackageName'>Kerberos</Data><Data Name='WorkstationName'>-</Data><Data Name='LogonGuid'>{XXX}</Data><Data Name='TransmittedServices'>-</Data><Data Name='LmPackageName'>-</Data><Data Name='KeyLength'>0</Data><Data Name='ProcessId'>0x0</Data><Data Name='ProcessName'>-</Data><Data Name='IpAddress'>XXX</Data><Data Name='IpPort'>55861</Data><Data Name='ImpersonationLevel'>%%1833</Data><Data Name='RestrictedAdminMode'>-</Data><Data Name='TargetOutboundUserName'>-</Data><Data Name='TargetOutboundDomainName'>-</Data><Data Name='VirtualAccount'>%%1843</Data><Data Name='TargetLinkedLogonId'>0x0</Data><Data Name='ElevatedToken'>%%1842</Data></EventData><RenderingInfo Culture='en-US'><Message>An account was successfully logged on.\r\n\r\nSubject:\r\n\tSecurity ID:\t\tS-1-0-0\r\n\tAccount Name:\t\t-\r\n\tAccount Domain:\t\t-\r\n\tLogon ID:\t\t0x0\r\n\r\nLogon Information:\r\n\tLogon Type:\t\t3\r\n\tRestricted Admin Mode:\t-\r\n\tVirtual Account:\t\tNo\r\n\tElevated Token:\t\tYes\r\n\r\nImpersonation Level:\t\tImpersonation\r\n\r\nNew Logon:\r\n\tSecurity ID:\t\tXXX\r\n\tAccount Name:\t\XXX$\r\n\tAccount Domain:\t\tXXX\r\n\tLogon ID:\t\tXXX\r\n\tLinked Logon ID:\t\t0x0\r\n\tNetwork Account Name:\t-\r\n\tNetwork Account Domain:\t-\r\n\tLogon GUID:\t\t{XXX}\r\n\r\nProcess Information:\r\n\tProcess ID:\t\t0x0\r\n\tProcess Name:\t\t-\r\n\r\nNetwork Information:\r\n\tWorkstation Name:\t-\r\n\tSource Network Address:\tXXX\r\n\tSource Port:\t\t55861\r\n\r\nDetailed Authentication Information:\r\n\tLogon Process:\t\tKerberos\r\n\tAuthentication Package:\tKerberos\r\n\tTransited Services:\t-\r\n\tPackage Name (NTLM only):\t-\r\n\tKey Length:\t\t0\r\n\r\nThis event is generated when a logon session is created. It is generated on the computer that was accessed.\r\n\r\nThe subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.\r\n\r\nThe logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).\r\n\r\nThe New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.\r\n\r\nThe network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.\r\n\r\nThe impersonation level field indicates the extent to which a process in the logon session can impersonate.\r\n\r\nThe authentication information fields provide detailed information about this specific logon request.\r\n\t- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.\r\n\t- Transited services indicate which intermediate services have participated in this logon request.\r\n\t- Package name indicates which sub-protocol was used among the NTLM protocols.\r\n\t- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.</Message><Level>Information</Level><Task>Logon</Task><Opcode>Info</Opcode><Channel>Security</Channel><Provider>Microsoft Windows security auditing.</Provider><Keywords><Keyword>Audit Success</Keyword></Keywords></RenderingInfo></Event>"}

when I pass this log in logtest, the deoder found is json but I don't have any other information.

I have done a lot of syslog/linux decoders but I have no ideas for Windows Event Logs. Do you have a lead?

Sincerely,

[Cristina Garrido López]

Hi Jérémy,

In order to monitor events from the new EventChannel version, agent and manager should have both versions 3.8.2 or higher. If you only have the right version for the agent, the events will be sent in the format of the message you pasted before, but they won't be decoded. When you update your manager, you should see every event in JSON format at your /var/ossec/logs/archives/archives.log file with the logall option from the ossec.conf file enabled.

Then, remember the steps I mentioned in the first messages:

- Remove the <category>ossec</category> option.

- Change the <decoded_as>windows_eventchannel</decoded_as> option by <decoded_as>json</decoded_as>.

At your 0575-win-base_rules.xml file included at the manager side.

In order to make new rules, you can focus in the event from the archives.log, and for example, if you want to filter by providerName and data of the next event:

{"win":{"system":{"providerName":"Microsoft-Windows-Winlogon","providerGuid":"{DBE9B383-7CF3-4331-91CC-A3CB16A3B538}","eventSourceName":"Wlclntfy","eventID":"6000","version":"0","level":"4","task":"0","opcode":"0","keywords":"0x80000000000000","systemTime":"2019-05-27T09:01:28.000000000Z","eventRecordID":"17593","processID":"0","threadID":"0","channel":"Application","computer":"pcname","severityValue":"INFORMATION","message":"The winlogon notification subscriber <SessionEnv> was unavailable to handle a notification event."},"eventdata":{"binary":"D9060000","data":"SessionEnv"}}}

Your rule would look like this:

<rule id="100000" level="3">

    <if_sid>60600</if_sid>

    <field name="win.system.providerName">Microsoft-Windows-Winlogon</field>

    <field name="win.eventdata.data">SessionEnv</field>

    <description>Winlogon event for SessionEnv</description>

</rule>

This is just an example, let me know if it helped and if you managed to see these JSON events.

Kind regards,

Cristina

[Jérémy]

thank you very much for your clarifications. We'll try that in the next few days.

See you soon

[Cristina Garrido López]

Happy to help! Let me know if you have any more doubts when you try this.

Best regards,

Cristina

[Jérémy]

Hi Cristina,

we have updated our Wazuh cluster to version 3.8.2. Indeed, Event Channel log management seems to have been greatly improved. The logs go up in Kibana without us having to make any changes!

However we do not have the rule file "0575-win-base_rules.xml" after the update?

Regards,

[Cristina Garrido López]

Hi Jeremy,

The file 0575-win-base_rules.xml is available since version 3.9.0. Eventchannel rules for lower versions are included at your 0220-msauth_rules.xml file. In order to check your custom rules with the changes I mentioned above, the rule you should modify is the one with ID 20000. Let me know if you have any doubts.

Kind regards,

Cristina