Glad it finally worked Phillipa :-) On Tue, Dec 1, 2015 at 5:28 PM, Phillipa Moorea <[email protected]> wrote:
> 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 <[email protected]> >>> 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 < >>>>>>>>> [email protected]> 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 [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.
