Hi,
it is very interesting. Right now, Wazuh is able to extract dynamic fields
and use them in the rule description. Example for your log:
**Phase 1: Completed pre-decoding.
full event: '2017 Mar 02 04:04:22 WinEvtLog: Security:
AUDIT_FAILURE(4656): Microsoft-Windows-Security-Auditing: (no user): no
domain: Desktop: A handle to an object was requested. Subject:
Security ID: S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account
Name: Subject1 Account Domain: DESKTOP Logon ID: 0xXXXXX Object:
Object Server: Security Object Type: File Object Name:
C:\Users\Subject2\Documents\Private.txt Handle ID: 0xXXX Resource
Attributes: - Process Information: Process ID: 0xXXX Process Name:
C:\Windows\System32\notepad.exe Access Request Information:
Transaction ID: {00000000-0000-0000-0000-000000000000} Accesses:
SYNCHRONIZE ReadData (or ListDirectory) Access Reasons:
SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;BU) ReadData (or
ListDirectory): Granted by D:(A;;0x1200a9;;;BU) Access Mask:
0x100001 Privileges Used for Access Check: - Restricted SID Count: 0'
hostname: 'ip-10-0-0-10'
program_name: 'WinEvtLog'
log: 'Security: AUDIT_FAILURE(4656):
Microsoft-Windows-Security-Auditing: (no user): no domain: Desktop: A
handle to an object was requested. Subject: Security ID:
S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXXX Account Name: Subject1
Account Domain: DESKTOP Logon ID: 0xXXXXX Object: Object Server:
Security Object Type: File Object Name:
C:\Users\Subject2\Documents\Private.txt Handle ID: 0xXXX Resource
Attributes: - Process Information: Process ID: 0xXXX Process Name:
C:\Windows\System32\notepad.exe Access Request Information:
Transaction ID: {00000000-0000-0000-0000-000000000000} Accesses:
SYNCHRONIZE ReadData (or ListDirectory) Access Reasons:
SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;BU) ReadData (or
ListDirectory): Granted by D:(A;;0x1200a9;;;BU) Access Mask:
0x100001 Privileges Used for Access Check: - Restricted SID Count: 0'
**Phase 2: Completed decoding.
decoder: 'windows'
status: 'AUDIT_FAILURE'
id: '4656'
extra_data: 'Microsoft-Windows-Security-Auditing'
dstuser: '(no user)'
system_name: 'Desktop'
account_name: 'Subject1'
account_domain: 'DESKTOP'
logon_id: '0xXXXXX'
accesses: ' SYNCHRONIZE ReadData (or ListDirectory)
Access Reasons: SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;BU)
ReadData (or ListDirectory): Granted by D:(A;;0x1200a9;;;BU)'
target_file: 'C:\Users\Subject2\Documents\Private.txt'
**Phase 3: Completed filtering (rules).
Rule id: '200000'
Level: '5'
Description: 'Unauthorized object access by Subject1'
**Alert to be generated.
The rule is:
<group name="windows-user-actions,">
<rule id="200000" level="5">
<if_sid>18105</if_sid>
<description>Unauthorized object access by *$(account_name)*
</description>
</rule>
</group>
Then you want to fire a rule *if account_name (Subject1) is a substring of
target_file (C:\Users\Subject2\Documents\Private.txt)*.
Unfortunately, it is not possible to do it, but it is in our roadmap to
improve the OSSEC rule engine. It will be something like:
<rule id="200000" level="5">
<if_sid>18105</if_sid>
*<condition>$(account_name) substr $(target_file)</condition>*
<description>Unauthorized object access by $(account_name)
</description>
</rule>
Feel free to send us use cases like this one and we will keep in mind for
the new rule engine. Also, we want to improve the correlation (if event A
and event B -> alert!).
Thanks for share it.
Regards.
On Thursday, March 2, 2017 at 9:27:30 AM UTC-8, dan (ddpbsd) wrote:
>
> On Thu, Mar 2, 2017 at 1:01 AM, InfoSec <gjah...@compucenter.org
> <javascript:>> wrote:
> > In the Wazuh fork, dynamic decoders are an outstanding idea. It allows
> > unprecedented visualization capabilities in the security console
> *without*
> > having to resort to further parsing tricks at ingestion time. It is all
> done
> > in OSSEC.
> >
> > Dynamic decoders enable unprecedented normalization of events. Dynamic
> > variables + dynamic decoders would tremendously boost OSSEC's host
> intrusion
> > detection capabilities, enabling modeling of attack scenarios that were
> > previously unthinkable in stock OSSEC.
> >
> > The above examples are a very basic illustration of the endless threat
> > scenario modeling possibilities that dynamic variables would add to
> Wazuh
> > fork of OSSEC.
> >
> > By the way, legitimate user names and domain names in Windows may
> contain
> > spaces. System events have "NT Authority" as domain name. The
> out-of-the-box
> > dynamic decoders fail and only picks up "NT" in the case of "NT
> Authority"
> > domain. Ditto for user names that contain spaces.
> >
> > The following work in case user name or domain contain spaces:
> >
> > <regex>Account Name:\s\s+(\w\.+)\s\s+Account Domain:</regex>
> >
> > and for domain names:
> >
> > <regex>Account Domain:\s\s+(\w\.+)\s\s+Logon ID:</regex>
> >
>
> I've submitted a PR with these changes, thanks!
> https://github.com/ossec/ossec-hids/pull/1080
>
> > --
> >
> > ---
> > 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 <javascript:>.
> > 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.
