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.
