On Tue, Aug 2, 2016 at 10:40 PM, lostinthetubez
<[email protected]> wrote:
> I’d give Wazuh a whirl, if I were you. They’ve got decoders and rules for
> sysmon, as well as eventchannel working (or I assume they do, if they have
> that stuff setup for sysmon).
>
>
>
> My current decoder/rule development server and agents have been around long
> enough that I don’t recall what sort of Frankenstein mixture of agent and
> server versions I am running. Now that I think back on it, I’m fairly
> certain I had to track down a fixed version of the Windows agent in the
> listserv archives to make 2.8.3 work.
>

Do you have more information on this? It doesn't sound familiar.

>
>
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Craig Mitchell
> Sent: Tuesday, August 2, 2016 7:13 PM
> To: [email protected]
>
>
> Subject: Re: [ossec-list] eventchannel decoder testing
>
>
>
> Thanks for the input! I'll take a closer look at 2.8.3 but the whole reason
> I was looking at 2.9RC2 was because it supported the eventchannel log type.
> From what I understand, 2.8.x had trouble with this and therefore had
> trouble with sysmon. Has that been your experience with 2.8.3? Thanks again
> everyone for the help.
>
>
>
> On Tue, Aug 2, 2016 at 8:49 PM, lostinthetubez <[email protected]>
> wrote:
>
> Craig,
>
>
>
> Hm... I just now noticed your exact symptoms while playing with a test OSSEC
> server that was created from a relatively recent git clone of the repository
> (cloned within the last month or two?). Take a look at your original output
> of ossec-logtest, under “Prepended Data Removed”. Look at the parsed “log:”
> field. Ossec-logtest is stripping “2016 Jul 29 22:32:24 WinEvtLog:” before
> processing it against the decoders. It isn’t supposed to be doing this. At
> least, this was not the behavior under 2.8.3. I do not have time to test the
> latest build from the repo to see if this problem has been fixed, though you
> might give that a whirl if you have the luxury of time. If you just want to
> make things work correctly, build your OSSEC server from the last known-good
> release, which is 2.8.3, or just follow Jesus’ suggestion and try out the
> Wazuh build.
>
>
>
>
>
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Craig
> Sent: Sunday, July 31, 2016 3:14 PM
> To: ossec-list <[email protected]>
> Subject: Re: [ossec-list] eventchannel decoder testing
>
>
>
> Great, thank you. That does help troubleshoot. So, I do have a follow up
> question. Here is the default decoder:
>
>
>
> <decoder name="Sysmon-EventID#1">
>
>   <type>windows</type>
>
>   <prematch>INFORMATION\(1\)</prematch>
>
>   <regex offset="after_prematch">Image: (\.*) \s*CommandLine: \.* \s*User:
> (\.*) \s*LogonGuid: \S* \s*LogonId: \S* \s*TerminalSessionId: \S*
> \s*IntegrityLevel: \.*HashType: \S* \s*Hash: (\S*) \s*ParentProcessGuid: \S*
> \s*ParentProcessID: \S* \s*ParentImage: (\.*) \s*ParentCommandLine:</regex>
>
>   <order>status,user,url,data</order>
>
> </decoder>
>
>
>
> However, when I remove the prepended data from my archives.log file and send
> it through logtest, the decoder doesn't work (if I leave the prepended data
> there, the decoder works). Any ideas why this might be happening? See below
> for my logtest:
>
>
>
> Prepended Data Removed:
>
>
>
> **Phase 1: Completed pre-decoding.
>
>        full event: '2016 Jul 29 22:32:24 WinEvtLog:
> Microsoft-Windows-Sysmon/Operational: INFORMATION(1):
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-PC1.hackme.local:
> Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid:
> {67C360F4-1FC8-579C-0000-001017F41E00}  ProcessId: 3988  Image:
> C:\Users\administrator\Desktop\svchost.exe  CommandLine:
> "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory:
> C:\Users\administrator\Desktop\  User: HACKME\Administrator  LogonGuid:
> {67C360F4-1C55-579C-0000-00206BBC0600}  LogonId: 0x6bc6b  TerminalSessionId:
> 1  IntegrityLevel: High  Hashes: MD5=C019D10F80409FC4C7D45EBFA48B0076
> ParentProcessGuid: {67C360F4-1C57-579C-0000-001092EC0600}  ParentProcessId:
> 3056  ParentImage: C:\Windows\explorer.exe  ParentCommandLine:
> C:\Windows\Explorer.EXE'
>
>        hostname: 'ubuntu-srv1'
>
>        program_name: 'WinEvtLog'
>
>        log: 'Microsoft-Windows-Sysmon/Operational: INFORMATION(1):
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-PC1.hackme.local:
> Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid:
> {67C360F4-1FC8-579C-0000-001017F41E00}  ProcessId: 3988  Image:
> C:\Users\administrator\Desktop\svchost.exe  CommandLine:
> "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory:
> C:\Users\administrator\Desktop\  User: HACKME\Administrator  LogonGuid:
> {67C360F4-1C55-579C-0000-00206BBC0600}  LogonId: 0x6bc6b  TerminalSessionId:
> 1  IntegrityLevel: High  Hashes: MD5=C019D10F80409FC4C7D45EBFA48B0076
> ParentProcessGuid: {67C360F4-1C57-579C-0000-001092EC0600}  ParentProcessId:
> 3056  ParentImage: C:\Windows\explorer.exe  ParentCommandLine:
> C:\Windows\Explorer.EXE'
>
>
>
> **Phase 2: Completed decoding.
>
>        No decoder matched.
>
>
>
> Prepended Data Intact:
>
>
>
> **Phase 1: Completed pre-decoding.
>
>        full event: '2016 Jul 29 22:32:25 (WIN7-X64-PC1)
> 172.16.213.5->WinEvtLog 2016 Jul 29 22:32:24 WinEvtLog:
> Microsoft-Windows-Sysmon/Operational: INFORMATION(1):
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-PC1.hackme.local:
> Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid:
> {67C360F4-1FC8-579C-0000-001017F41E00}  ProcessId: 3988  Image:
> C:\Users\administrator\Desktop\svchost.exe  CommandLine:
> "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory:
> C:\Users\administrator\Desktop\  User: HACKME\Administrator  LogonGuid:
> {67C360F4-1C55-579C-0000-00206BBC0600}  LogonId: 0x6bc6b  TerminalSessionId:
> 1  IntegrityLevel: High  Hashes: MD5=C019D10F80409FC4C7D45EBFA48B0076
> ParentProcessGuid: {67C360F4-1C57-579C-0000-001092EC0600}  ParentProcessId:
> 3056  ParentImage: C:\Windows\explorer.exe  ParentCommandLine:
> C:\Windows\Explorer.EXE'
>
>        hostname: '(WIN7-X64-PC1)'
>
>        program_name: '(null)'
>
>        log: '172.16.213.5->WinEvtLog 2016 Jul 29 22:32:24 WinEvtLog:
> Microsoft-Windows-Sysmon/Operational: INFORMATION(1):
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-PC1.hackme.local:
> Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid:
> {67C360F4-1FC8-579C-0000-001017F41E00}  ProcessId: 3988  Image:
> C:\Users\administrator\Desktop\svchost.exe  CommandLine:
> "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory:
> C:\Users\administrator\Desktop\  User: HACKME\Administrator  LogonGuid:
> {67C360F4-1C55-579C-0000-00206BBC0600}  LogonId: 0x6bc6b  TerminalSessionId:
> 1  IntegrityLevel: High  Hashes: MD5=C019D10F80409FC4C7D45EBFA48B0076
> ParentProcessGuid: {67C360F4-1C57-579C-0000-001092EC0600}  ParentProcessId:
> 3056  ParentImage: C:\Windows\explorer.exe  ParentCommandLine:
> C:\Windows\Explorer.EXE'
>
>
>
> **Phase 2: Completed decoding.
>
>        decoder: 'Sysmon-EventID#1'
>
>
>
>
>
>
>
>
>
>
> On Friday, July 29, 2016 at 11:22:46 AM UTC-5, LostInThe Tubez wrote:
>
> Delving into Sysmon event log parsing reveals just how monumental a task it
> is to parse out useful information from Windows event logs. The challenge is
> that nearly each and every Event ID has a different log format, which
> essentially means that almost every Event ID needs its own decoder... I may
> be waxing a little dramatic here, but the point is that to properly parse
> Windows logs, the original decoder needs to be made more generic and LOTS
> more child decoders need to be developed. At least, that is the approach I
> took, personally. Maybe I’m totally off base. Been testing it for a few
> months and it seems to work OK, but I haven’t done any auditing to see if
> I’ve broken anything. Anyway, here’s what I did and what works for me at the
> moment. If you go this route, you’ll need to comment out the original
> windows decoder in /var/ossec/etc/decoder.xml (and whatever else
> sysmon-related might have made it in there since last I looked; I’m not
> running the latest beta). I put these in local_decoder.xml:
>
>
>
> <decoder name="windows">
>
>         <type>windows</type>
>
>         <prematch>^\d\d\d\d \w\w\w \d\d \d\d:\d\d:\d\d WinEvtLog:
> |^WinEvtLog: </prematch>
>
> </decoder>
>
>
>
> <decoder name="windows-defaultlogs">
>
>         <parent>windows</parent>
>
>         <type>windows</type>
>
>         <use_own_name>true</use_own_name>
>
>         <prematch offset="after_parent">^Application: |^Security: |^System:
> </prematch>
>
>         <regex offset="after_parent">^\.+: (\w+)\((\d+)\): (\.+): </regex>
>
>         <regex>(\.+): \.+: (\S+): </regex>
>
>         <order>status, id, extra_data, user, system_name</order>
>
>         <fts>name, location, user, system_name</fts>
>
> </decoder>
>
>
>
> <decoder name="windows-sysmon-eventID1">
>
>         <parent>windows</parent>
>
>         <type>windows</type>
>
>         <prematch
> offset="after_parent">^Microsoft-Windows-Sysmon/Operational:
> INFORMATION\(1\)</prematch>
>
>         <regex offset="after_parent">^Microsoft-Windows-Sysmon/Operational:
> (\w+)\((\d)\): Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: (\S+):
> Process Create: \.+  ProcessId: \d+  Image: (\.*)  CommandLine: \.*</regex>
>
>         <regex>  User: (\.*)  LogonGuid: \S*  LogonId: \S*
> TerminalSessionId: \d*  IntegrityLevel: \w*  Hashes: \w+=(\w*)
> ParentProcessGuid: \S*  ParentProcessID: \S*  ParentImage: (\.+)</regex>
>
>         <order>status, id, system_name, dstuser, srcuser, url, extra_data,
> extra_data</order>
>
> </decoder>
>
>
>
>
>
> Put this in your local_rules.xml:
>
> <rule id="184600" level="1">
>
> <if_sid>18101</if_sid>
>
> <id>^1$</id>
>
> <description>Sysmon Process Launch Event</description>
>
> </rule>
>
>
>
> If you haven’t done so already, it is always helpful to enable logall mode
> when you’re working on new decoders. This will retain a copy of every single
> log line sent to your OSSEC manager. In your ossec.conf on the manager, put
> <logall>yes</logall> in a global tag somewhere and restart the service. You
> will now have a record of all logs sent to the manager, not just those that
> generate alerts. The current day’s archival logs are in
> /var/ossec/logs/archives/archives.log. Note that in order to run these
> particular logs through ossec-logtest, you’ll need to remove a prepended bit
> of text. So, edit a log entry like this:
>
>
>
> 2016 Jul 29 08:33:17 (hostname) 100.200.123.123->WinEvtLog 2016 Jul 29
> 08:36:08 WinEvtLog: Microsoft-Windows-Sysmon/Operational: INFORMATION(1):
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY:
> hostname.subdomain.domain.tld: Process Create:  UtcTime: 2016-07-29
> 15:36:08.268  ProcessGuid: {A560AB96-77E8-579B-0000-0010B7B17E50}
> ProcessId: 50292  Image: C:\Program Files (x86)\KeePass Password Safe
> 2\KeePass.exe  CommandLine: "C:\Program Files (x86)\KeePass Password Safe
> 2\KeePass.exe"   CurrentDirectory: C:\Program Files (x86)\KeePass Password
> Safe 2\  User: domain\username  LogonGuid:
> {A560AB96-40DE-578E-0000-00209886AB02}  LogonId: 0x2AB8698
> TerminalSessionId: 1  IntegrityLevel: Medium  Hashes:
> SHA1=5F5AC91EB83EFB6C4171AFF9EC1ED98EBA1C6A6C  ParentProcessGuid:
> {A560AB96-40E0-578E-0000-0010285AAC02}  ParentProcessId: 7540  ParentImage:
> C:\Windows\explorer.exe  ParentCommandLine: C:\Windows\Explorer.EXE
>
>
>
> to become:
>
> 2016 Jul 29 08:36:08 WinEvtLog: Microsoft-Windows-Sysmon/Operational:
> INFORMATION(1): Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY:
> hostname.subdomain.domain.tld: Process Create:  UtcTime: 2016-07-29
> 15:36:08.268  ProcessGuid: {A560AB96-77E8-579B-0000-0010B7B17E50}
> ProcessId: 50292  Image: C:\Program Files (x86)\KeePass Password Safe
> 2\KeePass.exe  CommandLine: "C:\Program Files (x86)\KeePass Password Safe
> 2\KeePass.exe"   CurrentDirectory: C:\Program Files (x86)\KeePass Password
> Safe 2\  User: domain\username  LogonGuid:
> {A560AB96-40DE-578E-0000-00209886AB02}  LogonId: 0x2AB8698
> TerminalSessionId: 1  IntegrityLevel: Medium  Hashes:
> SHA1=5F5AC91EB83EFB6C4171AFF9EC1ED98EBA1C6A6C  ParentProcessGuid:
> {A560AB96-40E0-578E-0000-0010285AAC02}  ParentProcessId: 7540  ParentImage:
> C:\Windows\explorer.exe  ParentCommandLine: C:\Windows\Explorer.EXE
>
>
>
> before copy/pasting into ossec-logtest. This is the best way to go about
> testing an eventchannel log. You get to see exactly what is decoded and
> which rules are triggered.
>
>
>
>
>
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Craig
> Sent: Thursday, July 28, 2016 8:24 PM
> To: ossec-list <[email protected]>
> Subject: [ossec-list] eventchannel decoder testing
>
>
>
> I am currently running 2.9RC2 on both client and server:
>
>
>
> What is the best way to go about testing an eventchannel log? I have the
> following set in my local ossec.conf on my windows agent:
>
>
>
> <localfile>
>
>   <location>Microsoft-Windows-Sysmon/Operational</location>
>
>   <log_format>eventchannel</log_format>
>
> </localfile>
>
>
>
> I am using the default sysmon decoder included on my server:
>
>
>
> <decoder name="Sysmon-EventID#1">
>
> <type>windows</type>
>
> <prematch>INFORMATION\(1\)</prematch>
>
> <regex offset="after_prematch">Image: (\.*) \s*CommandLine: \.* \s*User:
> (\.*) \s*LogonGuid: \S* \s*LogonId: \S* \s*TerminalSessionId: \S*
> \s*IntegrityLevel: \.*HashType: \S* \s*Hash: (\S*) \s*ParentProcessGuid: \S*
> \s*ParentProcessID: \S* \s*ParentImage: (\.*) \s*ParentCommandLine:</regex>
>
> <order>status,user,url,data</order>
>
> </decoder>
>
>
>
> I modified the default sysmon rule so that I would capture all process
> creates by setting the level to 1:
>
>
>
>  <rule id="184700" level="1">
>
>   <if_sid>18100</if_sid>
>
>   <description>Sysmon - Process Create Event</description>
>
>  </rule>
>
>
>
>
>
> I would think that i would now see all process creates in my alerts.log but
> unfortunately I don't see any sysmon events at all. Any idea on the best way
> to troubleshoot this? Thank you!
>
>
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ossec-list" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ossec-list/X0uBpH1nEDE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to