Windows Event Logs

[elvarb]

The Wazuh fork is really promising but it comes with the flaw of ossec is that it handles Windows Event Logs rather badly. There is so much content in them that can help identify problems that is not parsed, for example any usernames, file paths, domains and so on.

Parsing every single possible event format is not the best course of action but possibly the only option. I know that Windows Event Logs have more meta data in them than you can view through the xml view. Ossec sadly is not aware of it so to bring Wazuah to a level above Ossec getting that detailed information is incredibly valuable.

Are there any plans to modify the ossec client to get that information?

[santiago-bassett]

Hi @elvarb,

thanks for the suggestion. I agree with you that OSSEC is not parsing all we would like to get out of a Windows event.

Ideally we should be able to process most of them, but in any case, do you have examples of fields that you think could be interesting?

thank you!

[elvarb]

I am most used to nxlog as a log shipper and it handles the extra data fields and ships those as json. What nxlog also does is preserves the newlines so when viewing the log in Kibana the message field is easy to read compared to how it is with ossec.

But an example, windows event ID 4624, An account was successfully logged on.

Here are the fields that are included in the event that ossec ignores

SubjectUserSid
SubjectUserName 
SubjectDomainName
SubjectLogonId
TargetUserSid
TargetUserName
TargetDomainName
TargetLogonId
LogonType
LogonProcessName
AuthenticationPackageName Kerberos 
WorkstationName
LogonGuid
TransmittedServices
LmPackageName
KeyLength
ProcessId
ProcessName
IpAddress
IpPort
ImpersonationLevel
RestrictedAdminMode
TargetOutboundUserName
TargetOutboundDomainName
VirtualAccount
TargetLinkedLogonId
ElevatedToken

What are most important here are the TargetUserName, TargetLogonId and LogonType but I'm sure some of the others are very useful as well.

Sometimes though he values do not have a name but show up as Param1, Param2 and so on. Here is an example of that( %1, %2 and so on)

https://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Windows+Operating+System&ProdVer=5.2&EvtID=1074&EvtSrc=User32&LCID=1033

I have in the past used Logstash to parse the message field from Ossec but with limited success, which is why nxlog is simply easier to work with for Windows environments.

[elvarb]

There is a similar open issue for Elastic's Winlogbeat elastic/beats#465

[elvarb]

I found in the OSSEC windows client the file vista_sec.csv (or vista_sec.txt as it is in the source) that contains most events with the %1 values. For example:

4701, A scheduled task was disabled. Subject:  Security ID:  %1  Account Name:  %2  Account Domain:  %3  Logon ID:  %4  Task Information:  Task Name:   %5  Task Content:   %6
4704, A user right was assigned. Subject:  Security ID:  %1  Account Name:  %2  Account Domain:  %3  Logon ID:  %4  Target Account:  Account Name:  %5  New Right:  User Right:  %6

Do you know how the OSSEC agent uses this file?

[elvarb]

Found more issues related to this file

ossec/ossec-hids#550
ossec/ossec-hids#204 (comment)

[santiago-bassett]

Thank you @elvarb very useful. I'll leave the issue open, so we can have a detailed look at it.

[claudiopbail]

What´s the difference between Wazuh-Agent for Windows and Winlogbeat?

[alberpilot]

Hello @claudiopbail

Wazuh Agent and Winlogbeat are two very different tools. Winlogbeat reads and forwards Windows event logs. That's all. Wazuh agent is a security tool which has several plugins. One of those plugins is Logcollector which reads and forwards log lines and Windows event logs. But also is able to execute commands and forward the results. In Windows events, you can filter them, do queries, etc. In addition to this Wazuh Agent will send logs and the logs will be analyzed by the manager. The Wazuh Manager could determinate if the event received is an alert or if it can be ignored. Wazuh has ~1600 different rules for all kind of events and provides an engine to have custom rules. Custom rules joined the automatic JSON decoder system give to Wazuh the capability to easily analyze the most of the software logs actually. So, the Winlogbeat capabilities are contained in Wazuh Logcollector, but Wazuh agent is much more than that:

• Rootcheck: This process performs multiple tasks related to the detection of rootkits, malware and system anomalies. It also runs certain basic security checks against system configuration files.
• Log Collector: This agent component is used to read operating system and application log messages, including flat log files, standard Windows event logs, and even Windows Event Channels. It can also be configured to periodically run and capture the output of specific commands.
• Syscheck: This process performs file integrity monitoring (FIM) and can also monitor registry keys on Windows systems. It is capable of detecting changes in a file’s content, ownership, and other attributes, as well as noting the creation and deletion of files. While it performs periodic FIM scans by default, it can also be configured to communicate with the operating system kernel to do real-time detection of file changes and to produce a detailed change report (diffs) of text files.
• OpenSCAP: This module uses published OVAL (Open Vulnerability Assessment Language) and XCCDF (Extensible Configuration Checklist Description Format) baseline security profiles. By periodically scanning a system, it can find vulnerable applications or configurations that do not follow well-known standards, such as those defined in CIS (Center for Internet Security) benchmarks.
• Agent Daemon: This is the process that receives the data generated or collected by all other agent components. It compresses, encrypts and delivers the data to the server through an authenticated channel. This process runs in an isolated “chroot” (change root) environment, meaning that it has limited access to the monitored system. This improves the overall security of the agent because it is the only process that connects to the network.
• Virustotal integration: This allows the Manager to send the hashes of collected files (via Syscheck) to the VirusTotal API, reporting back the scan results and generating an alert when there is a positive result. The integration with VirusTotal as a threat intelligence source, along with the existing FIM capabilities is a significant improvement in Wazuh’s malware detection.
• CIS-CAT Wazuh module to scan CIS policies: The new CIS-CAT module was developed for evaluating CIS benchmarks in Wazuh agents. This module assesses an agent’s compliance with CIS policies to ensure the application of the best practices in the security of your IT systems. With the CIS-CAT wodle assessments can be scheduled to run periodically, sending reports to the manager and displaying results for each check.
• Future improvements: The OsQuery integration is in progress now.

If you need further information please let us know.
Best regards,
Alberto R

[vikman90]

Hi @elvarb,

This issue has been solved with the new implementation of the Windows EventChannel collector (#905), it's currently included in the Wazuh Agent for Windows.

I hope this adds value to the agent and allows to pick up all the fields of the events.

Let me close this issue.
Best regards.