Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[Jahchan, Georges J.]

Hello Jesus,

Following is the design recipe for an /advanced/ OSSEC correlation engine.

The engine is to have the following capabilities:
   i) Look forward and look back: Wait a certain time for next events,
-or- look back a certain time for previous events.
  ii) Conditions based on the content of decoded fields.
 iii) More than one condition can be specified simultaneously.
 iv) Boolean logic (at least the basic AND, OR, NOT) can be used in
conditions. Add regex to provide a further boost in capabilities.
  v) Stickiness: multiple occurrences of events with a field content
that matches (or does not match) that of the previous event in the sequence.
  Ex: Look for multiple occurrences of same events with same
IP/different port, or different IP/same port.
 vi) Generate a new custom event with a predefined alert level when a
correlation level is matched.
vii) Alert by e-mail (&/or SMS) when a correlation level is matched.

_Example_:
Correlation Trigger:
- Rule Level 1: X occurrences of event A matching one or more conditions
within a specified timeout period.
  Can be a single occurrence, at which time the Level 1 timeout becomes
irrelevant, level 2 timer kicks in.
  - Rules Level 2: Within XX seconds of matching Level 1 -or- in the XX
seconds preceding matching of Level 1, look for:
- Branch A - XX occurrences of:
  - Event B with 1 or more conditions relating to Level 1; -and-
  - Event C with 1 or more conditions relating to Level 1; -or-
  - ...
- Rules Level 3: Within XX seconds of matching Level 2 Branch A
-or- in the XX seconds preceding matching Level 2 Branch A, look for:
  - Branch C - XX occurrences of:
- Event D with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event E with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...
  *OR*
  - Branch D - XX occurrences of:
- Event F with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event G with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...
*OR*
- Branch B - XX occurrences of:
  - Event H with 1 or more conditions relating to Level 1; -and-
  - Event I with 1 or more conditions relating to level 1; -or-
  - ...
- Rules Level 3: Within XX seconds of matching Level 2 Branch B
-or- in the XX seconds preceding matching of Level 2 Branch B, look for:
  - Branch E - XX occurrences of:
- Event J with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event K with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...
  *OR*
  - Branch F - XX occurrences of:
- Event L with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event M with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...

Conditions for Branches at the same correlation level must be _mutually
exclusive_.

Example: if a condition for Branch A is 'audit success', for Branch B it
would be 'audit failure'. An event can be an audit success, or an audit
failure, _it cannot be both_. So at level 2 and below, the correlation
engine logic must branch to _only one Branch at a given level_. There
can be NO overlap between Branches at the same level. It is the
responsibility of the individual designing the correlation logic to
ensure the sanity of the logic behind it. Within a Branch, it is OK if
more than one rule matches.

Level 3 comes below Level 2 Branch A, and another Level 3 may come below
Level 2 Branch  B. Since Branch A and Branch B are mutually exclusive,
Branch C and Branch D at level 3 could be the same under branch A and
Branch B. Following the same principles, level 4 comes below level 3,
etc... As many levels as necessary can be defined.

Such an engine would allow alerting to:
  - Suspicious low and slow activity that attempts to remain below the
security monitoring radar -- provided one knows what to look for.
  - Scenarios with exponential growth in network connections (such as a
worm infection spreading).
  - Scenarios where a rapid recurrence of specific events occurs on
hosts (such as a ransomware infection).
  - Network footprinting: scans for a specific destination port on
multiple destination IPs.
  - Network footprinting: scans for a wide range of destination ports on
a single destination IP.
  - Dictionary attacks: repeated authentication failures from same
source targeting the same account name for all occurrences.
  - Dictionary attacks: repeated authentication failures from same
source targeting a different account name for each occurrence.

- When a correlation level is matched, if within the specified timeout
period (forward or backward) all the branches for the
  level below do not match, remove from correlation.
- A 

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[Jesus Linares]

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-XX-XX-XX-   Account 
Name:  Subject1  Account Domain:  DESKTOP   Logon ID:  0xXObject:   
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.exeAccess Request Information:   
Transaction ID:  {----}   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: 
 0x11   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-XX-XX-XX-   Account Name:  Subject1 
 Account Domain:  DESKTOP   Logon ID:  0xXObject:   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.exeAccess Request Information:   
Transaction ID:  {----}   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: 
 0x11   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: '0xX'
   accesses: ' SYNCHRONIZE  ReadData (or ListDirectory) 
Access Reasons:  SYNCHRONIZE: Granted byD:(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: '20'
   Level: '5'
   Description: 'Unauthorized object access by Subject1'
**Alert to be generated.

The rule is:


18105
Unauthorized object access by *$(account_name)*




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:


18105
*$(account_name) substr $(target_file)*
Unauthorized object access by $(account_name)



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  > 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: 
> > 
> > Account Name:\s\s+(\w\.+)\s\s+Account Domain: 
> > 
> > and for domain names: 
> > 
> > 

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[dan (ddp)]

On Thu, Mar 2, 2017 at 1:01 AM, InfoSec  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:
>
> Account Name:\s\s+(\w\.+)\s\s+Account Domain:
>
> and for domain names:
>
> Account Domain:\s\s+(\w\.+)\s\s+Logon ID:
>

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+unsubscr...@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.

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[InfoSec]

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:

Account Name:\s\s+(\w\.+)\s\s+Account Domain:

and for domain names:

Account Domain:\s\s+(\w\.+)\s\s+Logon ID:

-- 

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

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[InfoSec]

Sure thing.

I am trying to implement three use cases.

1) Windows event ID: Failed object access attempt by a subject "Subject" 
(tied to a real user, not a system account) of Object Type: File and 
object: "C:\Users\Other-than-Subject\Whatever-else comes after.ext". Ten 
recurrences by same Subject --> trigger an e-mail alert.

Here's what the event look like. The content of all the fields is decoded 
in Wazuh fork of OSSEC.

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-XX-XX-XX- Account Name: Subject1 
Account Domain: DESKTOP Logon ID: 0xX 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: {----} 
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: 0x11 Privileges Used for 
Access Check: - Restricted SID Count: 0

During decoding, the values of Account Name are stored as "subject", Object 
Name as "object", the main directory in object as obj_dir_1, and first 
subdirectory as obj_dir_2. In the example above obj_dir_1 is "Users" and 
obj_dir_2 is "Subject2".

Practically, if an event similar to the above occurs where the value of 
obj_dir_1 is "Users" *and* the value of decoded field "subject" does *not* 
match the value of decoded field "obj_dir_2" ten times in half an hour from 
same subject trigger an e-mail alert.

2) User successfully accessing files in the home folder of another user --> 
A single occurrence generates an *immediate *e-mail alert.

2017 Mar 02 04:04:22 WinEvtLog: Security: AUDIT_SUCCESS(4656): Microsoft-
Windows-Security-Auditing: (no user): no domain: Desktop: A handle to an 
object was requested. Subject: Security ID: 
S-1-5-21-XX-XX-XX- Account Name: Subject1 
Account Domain: DESKTOP Logon ID: 0xX 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: {----} 
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: 0x11 Privileges Used for 
Access Check: - Restricted SID Count: 0

Practically, if a single event similar to the above occurs where the value 
of subject does *not* match the value of obj_dir_2 *and* obj_dir_1 is 
"Users" trigger an e-mail alert.

Use case 1 is a security incident that can be described as: repeated failed 
attempts at unauthorized object access by user.

Use case 2 is a more serious security incident: confirmed successful 
unauthorized object access by user due to a loophole in the access control 
list on Object. If subject1 is a *privileged *account, this is a clear 
abuse of privilege by a system administrator.

Use Case 3 is an even more serious incident: one or more use case 1 
followed by use case 2. Subject successfully managed to modify the ACL on 
Object (then we would expect to see evidence thereto in the logs in terms 
of changed permissions events -- another use case) or managed to subvert or 
bypass the access control mechanism.

-- 

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

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[Jesus Linares]

Hi,

could you give us a real example?.

Thanks

On Wednesday, March 1, 2017 at 10:34:18 AM UTC-8, dan (ddpbsd) wrote:
>
> On Mon, Feb 27, 2017 at 2:50 PM, Jahchan, Georges J. 
>  wrote: 
> > That is not what I meant. 
> > 
> > If the source IP is decoded and stored in field srcip, I want to be able 
> to 
> > specify _srcip_ (or whatever convention used to tell regex that this is 
> a 
> > variable), and have _srcip_ replaced by the value saved as srcip in the 
> > event. 
> > 
> > If srcip is 10.0.0.1, specifying in the regex 
> > Some-regex-preceding-_srcip_-some regex tailing _srcip_ 
> in 
> > the regex would be dynamically replaced by its value (10.0.0.1) during 
> regex 
> > evaluation. 
> > 
>
> There's no support for that. 
>
> > -- 
> > 
> > --- 
> > 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.

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[dan (ddp)]

On Mon, Feb 27, 2017 at 2:50 PM, Jahchan, Georges J.
 wrote:
> That is not what I meant.
>
> If the source IP is decoded and stored in field srcip, I want to be able to
> specify _srcip_ (or whatever convention used to tell regex that this is a
> variable), and have _srcip_ replaced by the value saved as srcip in the
> event.
>
> If srcip is 10.0.0.1, specifying in the regex
> Some-regex-preceding-_srcip_-some regex tailing _srcip_ in
> the regex would be dynamically replaced by its value (10.0.0.1) during regex
> evaluation.
>

There's no support for that.

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

-- 

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

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[Jahchan, Georges J.]

That is not what I meant.

If the source IP is decoded and stored in field srcip, I want to be able
to specify _srcip_ (or whatever convention used to tell regex that this
is a variable), and have _srcip_ replaced by the value saved as srcip in
the event.

If srcip is 10.0.0.1, specifying in the regex
Some-regex-preceding-_srcip_-some regex tailing _srcip_
in the regex would be dynamically replaced by its value (10.0.0.1)
during regex evaluation.

-- 

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [ossec-list] Dynamic values in regex inside OSSEC rules?

[dan (ddp)]

On Feb 26, 2017 11:45 AM, "InfoSec"  wrote:

Is it possible to refer to the content of a decoded field by its field
name inside a regex in a rule?

Example: after decoding an event, we have two fields among several, field1
and field2.

The event contains:
... Field1 Label: Content_of_Field1   Field2 Label: Content_of_Field2
  Field3 Label: Content_of_Field3 ...

The regex follows:

Field2 Label:\sSome regex followed by reference_to_field1 followed
by some other regex\sField3 Label:

'reference_to_field1' would be *dynamically *substituted by
Content_of_Field1 when evaluating the regex.

If possible, how?

If currently not possible, consider this a feature request.


You should be able to reference fields directly. For example, if you decode
a srcip, you can add the following to a rule:
10.0.0.1 


-- 

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

-- 

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

[ossec-list] Dynamic values in regex inside OSSEC rules?

[InfoSec]

Is it possible to refer to the content of a decoded field by its field 
name inside a regex in a rule?

Example: after decoding an event, we have two fields among several, field1 
and field2.

The event contains:
... Field1 Label: Content_of_Field1   Field2 Label: Content_of_Field2 
  Field3 Label: Content_of_Field3 ...

The regex follows:

Field2 Label:\sSome regex followed by reference_to_field1 followed 
by some other regex\sField3 Label:

'reference_to_field1' would be *dynamically *substituted by 
Content_of_Field1 when evaluating the regex.

If possible, how?

If currently not possible, consider this a feature request.

-- 

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