Yeah, I finally got the alerts working. This post helped me out alot: https://groups.google.com/forum/#!searchin/ossec-list/alert$20to$20be$20generated/ossec-list/SWJe7nm2cbU/pKc8HSfDXCEJ
It shows exactly a log inside of the archive.log, and what you should paste into the ossec-logtest. I also found somewhere to run ossec-logtest with the "-v" flag option to show the rule matches too. After I got that, I found that other rules would match causing the level to be 0. Rule 6 matches which was a generic windows rule. Rule 18100 matched with some logs which is the "Group of windows rules" I changed the "<if_sid>" to the 18100 as suggested by Santiago, and then ran the test again. It worked. So I actually tested it in a real test scenario, and it worked!! Alarms were generated in the alarms.log file. THANK YOU everyone for all of your help. After a bunch of fixes, configuration fixes, OSSEC upgrades, buying an OSSEC book off of amazon, and these forums, I was finally able to get it to work. :) YEAH!! On Tuesday, December 1, 2015 at 6:43:58 PM UTC-6, Phillipa Moorea wrote: > > Thanks Santiago for the information about OSSIM. > > I do not have conditions for "if_sid" in the rules. I'm not sure what I > would even put there since this is the first rule for PowerShell events. I > currently have set the alert level on the rule to 2. I tried other values, > but nothing was working there. I'm still trying to debug why an alert is > not generating, even though when I run the ossec-logtest, it says that an > alert will be generated.... > > > On Tuesday, December 1, 2015 at 6:37:03 PM UTC-6, Santiago Bassett wrote: >> >> I haven't have time to go through the whole email thread, but I don't >> think using OSSEC in AlienVault OSSIM would cause this. The only >> modification AlienVault does to OSSEC is the format used for alerts output >> (at alerts.log), so it can easily be parsed by the AlienVault plugin. >> >> Regarding your other question, please check that conditions of <if_sid> >> rules are also met, and that ultimately the alert level is different than 0. >> >> Hope that helps >> >> On Tue, Dec 1, 2015 at 4:32 PM, Phillipa Moorea <philli...@gmail.com> >> wrote: >> >>> I had before restarted only OSSEC, but now I tried restarting the >>> server, but no fixes yet. >>> >>> Could the issue be caused by the use of OSSEC on an AlienVault OSSIM >>> server? >>> >>> >>> On Tuesday, December 1, 2015 at 5:40:19 PM UTC-6, Phillipa Moorea wrote: >>>> >>>> Could the problem (of not creating alerts) be caused because PowerShell >>>> events are INFORMATIONAL? >>>> >>>> Informational Event Codes generated by PowerShell: 400, 403, 500, 501, >>>> 600 >>>> >>>> >>>> >>>> On Monday, November 30, 2015 at 1:05:35 PM UTC-6, Phillipa Moorea wrote: >>>>> >>>>> Here's another example of a log file in which I'm actually interested >>>>> in: >>>>> >>>>> 2015 Nov 30 13:02:39 (HOSTNAME) HOSTIP->WinEvtLog 2015 Nov 30 13:02:39 >>>>> WinEvtLog: Windows PowerShell: INFORMATION(500): PowerShell: (no user): >>>>> no >>>>> domain: HOSTNAME_FQDN: Command "Get-Host" is Started. Details: >>>>> NewCommandState=Started SequenceNumber=41 HostName=ConsoleHost >>>>> HostVersion=2.0 HostId=9579f128-903c-463c-80fa-7eaa4a80dc54 >>>>> EngineVersion=2.0 RunspaceId=c07bf134-24b9-47f7-9dfe-9732dc3e675d >>>>> PipelineId=5 CommandName=Get-Host CommandType=Cmdlet ScriptName= >>>>> CommandPath= CommandLine=Get-Host >>>>> >>>>> This log actually shows the command name that was ran "Get-Host" was >>>>> my test Powershell command. If there was a script, then the ScriptName >>>>> would be populated. >>>>> >>>>> >>>>> On Monday, November 30, 2015 at 12:54:50 PM UTC-6, Phillipa Moorea >>>>> wrote: >>>>>> >>>>>> Also, thanks for the information about the groups >>>>>> >>>>>> On Monday, November 30, 2015 at 10:15:26 AM UTC-6, Phillipa Moorea >>>>>> wrote: >>>>>>> >>>>>>> Hi Dan! Here's a log from my archives.log file >>>>>>> >>>>>>> 2015 Nov 30 10:07:57 (HOSTNAME) HOSTIP->WinEvtLog 2015 Nov 30 >>>>>>> 10:07:54 WinEvtLog: Security: AUDIT_SUCCESS(4688): >>>>>>> Microsoft-Windows-Security-Auditing: (no user): no domain: >>>>>>> HOSTNAME_FQDN: A >>>>>>> new process has been created. Subject: Security ID: >>>>>>> S-1-5-21-1292428093-1078145449-842925246-500 Account Name: >>>>>>> Administrator >>>>>>> Account Domain: DOMAIN Logon ID: 0x6b008a65 Process Information: >>>>>>> New >>>>>>> Process ID: 0xeac New Process Name: >>>>>>> C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Token >>>>>>> Elevation >>>>>>> Type: %%1936 Creator Process ID: 0x2068 >>>>>>> >>>>>>> I also get other similar powershell event logs with this type of >>>>>>> unique message info: >>>>>>> handle to an object was closed >>>>>>> a process has exited >>>>>>> handle to an object was requested >>>>>>> privileges used for access check >>>>>>> >>>>>>> in addition to the log above which has the message "a new process >>>>>>> has been created" >>>>>>> >>>>>>> On Monday, November 30, 2015 at 7:52:14 AM UTC-6, dan (ddpbsd) wrote: >>>>>>>> >>>>>>>> On Mon, Nov 30, 2015 at 6:39 AM, Phillipa Moorea < >>>>>>>> philli...@gmail.com> wrote: >>>>>>>> > If anybody knows what I am doing wrong, any help would be great. >>>>>>>> Even just >>>>>>>> > a documentation link or something or a question of >>>>>>>> clarification? I have >>>>>>>> > posted this issue in the AlienVault forums as well. I've been >>>>>>>> keeping both >>>>>>>> > forums updated. >>>>>>>> > >>>>>>>> >>>>>>>> Can you post an entry from the archives.log after the eventchannel >>>>>>>> change? >>>>>>>> >>>>>>>> > I think a lot of people will want to monitor any scripts from the >>>>>>>> command >>>>>>>> > line and from PowerShell that run on one of their servers or >>>>>>>> workstations. >>>>>>>> > If bad malware gets onto a device, it usually runs scripts, so >>>>>>>> this is part >>>>>>>> > of my detection technique to alert me if a script is ran. I'm >>>>>>>> still working >>>>>>>> > on the rules. >>>>>>>> > >>>>>>>> > This is my current rule setup in the local_rules.xml file: >>>>>>>> > >>>>>>>> > <group name="local,syslog,"> >>>>>>>> > <rule id="100210" level="6"> >>>>>>>> > <id>^400$|^403$|^500$|^501$|^600$</id> >>>>>>>> > <description>Powershell Event.</description> >>>>>>>> > </rule> >>>>>>>> > <rule id="100211" level="6"> >>>>>>>> > <match>CommandType=Cmdlet</match> >>>>>>>> > <description>Powershell Command.</description> >>>>>>>> > </rule> >>>>>>>> > <rule id="100212" level="6"> >>>>>>>> > <match>PowerShell</match> >>>>>>>> > <description>Powershell Log.</description> >>>>>>>> > </rule> >>>>>>>> > </group> >>>>>>>> > >>>>>>>> > I'm not sure if the group name matters or needs to be something >>>>>>>> specific? >>>>>>>> > >>>>>>>> >>>>>>>> The group names shouldn't affect much. >>>>>>>> >>>>>>>> > >>>>>>>> > On Friday, November 27, 2015 at 9:06:21 AM UTC-6, Phillipa Moorea >>>>>>>> wrote: >>>>>>>> >> >>>>>>>> >> A little further, I changed the logformat from eventlog to >>>>>>>> eventchannel, >>>>>>>> >> and now the archive.log has taken out all of the multiple >>>>>>>> lines. I still do >>>>>>>> >> not have a generated alert yet even though ossec-logtest says it >>>>>>>> generates >>>>>>>> >> an alert and it matches my custom rule. I set the level to >>>>>>>> level 6. >>>>>>>> >> >>>>>>>> >> On Friday, November 27, 2015 at 8:41:48 AM UTC-6, Phillipa >>>>>>>> Moorea wrote: >>>>>>>> >>> >>>>>>>> >>> Well, I updated both the server and client OSSEC HIDS to 2.8.3, >>>>>>>> but still >>>>>>>> >>> no luck. The PowerShell logs in archive.log are still >>>>>>>> multi-line logs, and >>>>>>>> >>> I am getting the same results. >>>>>>>> >>> >>>>>>>> >>> On Wednesday, November 25, 2015 at 8:45:18 AM UTC-6, Phillipa >>>>>>>> Moorea >>>>>>>> >>> wrote: >>>>>>>> >>>> >>>>>>>> >>>> Ok, I think I know what's going on now. I do not have the >>>>>>>> latest stable >>>>>>>> >>>> release of 2.8.3. I think I might have 2.8.2 or 2.8.1 or >>>>>>>> something. >>>>>>>> >>>> >>>>>>>> >>>> I found this issue which resembled my issue because the logs >>>>>>>> have >>>>>>>> >>>> multiple lines in powershell. >>>>>>>> >>>> https://github.com/ossec/ossec-hids/issues/224 >>>>>>>> >>>> Then I saw that a fix was implemented in 2.9 from here: >>>>>>>> >>>> https://github.com/ossec/ossec-hids/pull/457 >>>>>>>> >>>> Then from this forum I now see that perhaps it is implemented >>>>>>>> in 2.8.3 >>>>>>>> >>>> on Nov 5th which is probably the day after I had made my OSSEC >>>>>>>> updates, lol: >>>>>>>> >>>> https://groups.google.com/forum/#!topic/ossec-list/JA9x4uzDg1g >>>>>>>> >>>> >>>>>>>> >>>> I'll try updating to the latest version again and see if that >>>>>>>> helps. >>>>>>>> >>>> >>>>>>>> >>>> On Monday, November 9, 2015 at 9:17:28 AM UTC-6, Phillipa >>>>>>>> Moorea wrote: >>>>>>>> >>>>> >>>>>>>> >>>>> I have restarted OSSEC using the OSSEC Agent Manager on the >>>>>>>> ossec >>>>>>>> >>>>> client computer. I have also restarted the OSSEC service on >>>>>>>> the OSSEC >>>>>>>> >>>>> server. I'm not sure why I can't reply to your response, so >>>>>>>> I had to reply >>>>>>>> >>>>> to mine @dan(ddpbsd) >>>>>>>> >>>>> >>>>>>>> >>>>> Also I am using OSSEC HIDS v2.8 on the client & server. >>>>>>>> > >>>>>>>> > -- >>>>>>>> > >>>>>>>> > --- >>>>>>>> > 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 ossec-list+...@googlegroups.com. >>>>>>>> > 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 ossec-list+...@googlegroups.com. >>> 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 ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
