Tag Archives: OSSEC

New Sysmon OSSEC Decoders….

Jesús Linares / Wazuh have recently released OSSEC decoders for all current (v3.11) Sysmon EventIDs. Up until this point, I had been maintaining primarily just EventID 1 (Process Creation), but now we have the added benefits of parsed logs for the following Sysmon Events:

ID2: A process changed a file creation time

ID3: Network Connections

ID4: Sysmon service state changed

ID5: Process Terminated

ID6: Driver Loaded

ID7: Image Loaded

ID8: CreateRemoteThread

This is a great addition, as we can now start writing rules against thread injection events, unsigned drivers being loaded, etc.

You can find the decoders on Github: https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/decoders/windows_decoders.xml

-Josh

 

 

Tagged ,

Sysmon & Security Onion, Part 5: Sysmon Event Collection

This is part five of a series of posts that contain key excerpts of my paper, Using Sysmon to Enrich Security Onion’s Host-Level Capabilities.

Two different methods could be employed to collect the Sysmon events from the local client. Possible approaches use only OSSEC or a hybrid architecture where OSSEC and Windows Event Collection are utilized together.

OSSEC

    One way to collect the Sysmon events from all installed clients would be to use the Host Intrusion Detection System (HIDS) that Security Onion includes, which is OSSEC. This architecture would include installing OSSEC on all servers and workstations, and configuring it through the option to send Sysmon logs to Security Onion. (Windows Eventchannel Example) If this were the only function that OSSEC would be used for, most organizations would be reticent to deploy another client to their workstations and servers, especially when there are other, more efficient options to collect the Sysmon data.

Hybrid

    The architecture that the author has used and recommends is that of a hybrid model. This would include installing OSSEC only on servers, as there are typically other types of logs that need collection as well. For workstations, the use of the Windows Event Collector framework is recommended to collect all of the Sysmon logs onto a central Windows system. (Helweg) With the logs all in one location, an OSSEC client can be installed on the collection server, which would process all of the logs and ship them off to the Security Onion sensor. For offsite users, events can still be collected by making the collector server publically available. Refer to the following diagram for what this particular architecture would look like:

Hybrid Collection

Diagram of hybrid collection model

 

     Now that the logs have been collected and shipped to the Security Onion sensor, they must be processed by both OSSEC and ELSA before the data can be used by either of those tools. Because Sysmon is relatively new, the author of this paper was required to write his own parsers for both ELSA and OSSEC to be able to pull out the relevant data contained in Sysmon events.

References:

Windows Eventchannel Example. (n.d.). Retrieved February 22, 2015, from OSSEC Docs: http://ossec-docs.readthedocs.org/en/latest/manual/monitoring/file-log-monitoring.html#windows-eventchannel-example

Helweg, O. (2008, July 8). Quick and Dirty Enterprise Eventing for Windows. Retrieved from TechNet: http://blogs.technet.com/b/otto/archive/2008/07/08/quick-and-dirty-enterprise-eventing-for-windows.aspx

Tagged , , ,

Sysmon & Security Onion: Monitoring Key Windows Processes for Anomalies

One of the sections of my recently released paper works through how to use Sysmon logs to monitor key windows processes for anomalous behavior. One issue that I wanted to make clear–The current OSSEC ruleset on Github is based on this document that I maintain: http://DefensiveDepth.com/Windows-Processes, which itself is based on a few different sources, namely the SANS Know Normal… Find Evil, Know your Windows Processes or Die Trying,  as well as my own experience. Any feedback that you can give to tweak the documentation and/or rules would be much appreciated.

From the paper, Using Sysmon to Enrich Security Onion’s Host-Level Capabilities:

So as to be able to maintain persistence, both targeted and opportunistic threats use certain techniques to attempt to blend into the background of a busy system. One of the primary ways of doing this is by emulating and/or abusing legitimate Windows processes. For instance, malware named svhost.exe instead of svchost.exe, which is a legitimate process. Another example would be the Poweliks class of malware, which hollows out a legitimate process and runs its malicious threads from there. In fact, in the case of Poweliks, there is no binary downloaded to the system itself, as it runs entirely in memory.

Using the host data generated by Sysmon, detection of these techniques can become commonplace. The crux of the idea is that it is well known how critical legitimate Windows processes should be running. Let us take a closer look at this detection strategy. The current iteration of Poweliks hollows a legitimate Windows process, dllhost.exe, to perform its malicious tasks. (Harrell, 2014) When the author ran a copy of Poweliks on a system with Sysmon installed, the following pertinent data was generated:

 

         Image: C:\Windows\syswow64\dllhost.exe

         CommandLine: C:\Windows\syswow64\dllhost.exe

 

         ParentImage: C:\Windows\syswow64\windowspowershell\v1.0\powershell.exe

         ParentCommandLine: “C:\Windows\syswow64\windowspowershell\v1.0\power shell.exe” iex $env:a

 

Typically dllhost.exe’s parent process would be svchost.exe, and at runtime, dllhost.exe would be passed the following parameter: /Processid:{}. As can be seen, the dllhost.exe that is started by Poweliks falls outside the norm, and would have set off some alerts.

Based on this concept, the I wrote more than ten OSSEC rules that cover normal behavior for a number of critical Windows processes. These rules can be found on Github. Keep in mind that the rules were written with the corresponding OSSEC decoder for Sysmon logs, so they may need to be edited if used outside of that particular context. When writing the rules, there were a number of ways to alert on abnormal behavior: Image Location, User Context, Parent Process Image, and finally, how many instances should be running on the system. For simplicity, the ruleset was designed to alert on one abnormal attribute. The most immutable attribute would seem to be the parent image, which is why the ruleset only looks at the parent image for abnormalities. Within this attribute, two abnormalities are checked for. The first is whether the parent process image is known-good. For example, the parent image of svchost.exe should only ever be C:\Windows\System32\services.exe. The second abnormality is that there are a couple processes that should never spawn a child process—lsm.exe and lsass.exe. With this being the case, there are a few rules that look for these particular images as the parent process image and alert if found.

References:

SANS. (n.d.). Know Abnormal… Find Evil. Retrieved February 12, 2015, from sans.org: http://digital-forensics.sans.org/media/poster_2014_find_evil.pdf

Harrell, C. (2014, December 17). Prefetch File Meet Process Hollowing. Retrieved from Journey Into Incident Response: http://journeyintoir.blogspot.com/2014/12/prefetch-file-meet-process-hollowing_17.html

Tagged , , , ,