Thanks Phillipa for sharing. So good to see you actually integrated it with
AlienVault OSSIM too.

On Wed, Dec 2, 2015 at 1:02 PM, Phillipa Moorea <[email protected]>
wrote:

> Thanks for all the help from you (Santiago), from dan, some other posts on
> here, github repository issues, a book I bought on ossec for $10, and the
> work of the OSSEC developers that made the 2.8.3 update, and of course the
> people in the AlienVault Labs!
>
> I was now able to get the alerts working.  I analyzed the PowerShell logs
> and changed my rules a bit.  Here is what I changed it too:
>
> <group name="powershell,">
>   <rule id="100210" level="0">
>     <if_sid>18100,18101</if_sid>
>     <match>CommandType=Script</match>
>     <description>Powershell Script.</description>
>   </rule>
>   <rule id="100211" level="0">
>     <if_sid>18100,18101</if_sid>
>     <match>CommandType=Cmdlet</match>
>     <description>Powershell Command.</description>
>   </rule>
>   <rule id="100212" level="0">
>     <if_sid>18100,18101</if_sid>
>     <match>CommandType=Function</match>
>     <description>Powershell Function.</description>
>   </rule>
>   <rule id="100213" level="2">
>     <if_sid>100210</if_sid>
>     <match>NewCommandState=Started</match>
>     <description>Powershell Script (500-Started).</description>
>   </rule>
>   <rule id="100214" level="2">
>     <if_sid>100210</if_sid>
>     <match>NewCommandState=Stopped</match>
>     <description>Powershell Script (501-Stopped).</description>
>   </rule>
>   <rule id="100215" level="2">
>     <if_sid>100211</if_sid>
>     <match>NewCommandState=Started</match>
>     <description>Powershell Command (500-Started).</description>
>   </rule>
>   <rule id="100216" level="2">
>     <if_sid>100211</if_sid>
>     <match>NewCommandState=Stopped</match>
>     <description>Powershell Command (501-Stopped).</description>
>   </rule>
>   <rule id="100217" level="2">
>     <if_sid>100212</if_sid>
>     <match>NewCommandState=Started</match>
>     <description>Powershell Function (500-Started).</description>
>   </rule>
>   <rule id="100218" level="2">
>     <if_sid>100212</if_sid>
>     <match>NewCommandState=Stopped</match>
>     <description>Powershell Function (501-Stopped).</description>
>   </rule>
> </group> <!-- POWERSHELL -->
>
> I have also created a custom OSSIM plugin for AlienVault to get the alerts
> into the SEIM:
> /etc/ossim/agent/plugins/powershell.cfg: (ATTACHED FILE)
> /etc/ossim/agent/plugins/powershell.sql: (ATTACHED FILE)
>
> It's probably not the best structure, but it works pretty well and is a
> good start!
>
>
>
> On Wednesday, December 2, 2015 at 1:16:09 PM UTC-6, Santiago Bassett wrote:
>>
>> 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.
>

-- 

--- 
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