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:

<snip>... Field1 Label: Content_of_Field1   Field2 Label: Content_of_Field2   Field3 Label: Content_of_Field3 ...</snip>

The regex follows:

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

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

[dan (ddp)]

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

<srcip>10.0.0.1 </srcip>

--

---
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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 <regex>Some-regex-preceding-_srcip_-some regex tailing</regex> _srcip_ in the regex would be dynamically replaced by its value (10.0.0.1) during regex evaluation.

[dan (ddp)]

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.

[Jesus Linares]

Hi,

could you give us a real example?.

Thanks

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

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

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.

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

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

[dan (ddp)]

I've submitted a PR with these changes, thanks!
https://github.com/ossec/ossec-hids/pull/1080

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

[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 match at any level may need to trigger an email alert and/or create a new correlation engine generated event.
- Correlation engine generated events may be used to trigger other correlations.
- Correlation engine generated events may be used in other correlations.

Almost any suspicious activity use case could be modeled in an engine that has the capabilities detailed above. The logic can be simple (single level) or  convoluted (as many levels and branches as one wishes to put in it).

[Jesus Linares]

Hi,

thanks so much for the detailed response. I will study your recommendations in order to improve the rule engine. My concerns are about the CPU/memory usage. This feature requires a deep research and it has implications at a very technical level.

I will let you know when we improve something related with the rule engine.

Thanks.

Regards.